[Bf-committers] blender as ui for game engine

Thu Jan 21 10:16:53 CET 2016

http://homac.cakelab.org/projects/JavaBlend/ but I did not dig for a git
etc.
On Jan 21, 2016 1:07 AM, "Owen Hogarth II" <gurenchan at gmail.com> wrote:

> How long ago was that email sent and where is the code now?
>
> Best,
> Owen
>
> On Thu, Jan 21, 2016 at 5:02 PM, Jacob Merrill <blueprintrandom1 at gmail.com
> >
> wrote:
>
> > actually I found the email I was digging at, it appears he got it
> working?
> >
> > Hello There!
> >
> >
> > As some of you know, I've implemented a toolkit, consisting of a code
> > generator and a runtime I/O module to map the full Blender DNA to Java
> > classes and allow reading and writing of files (cf. [1]).
> >
> > All that is fine but won't help a developer as long as he/she don't know
> > the meaning of those generated classes and its member variables. Thus,
> > they will need source code documentation, to be provided in the
> > generated code.
> >
> > Since providing documentation to blender sources is not the right way, I
> > came up with the idea to provide a documentation system, maintained
> > separate from blender source. I picked that up in the Minecraft modder
> > community, and thought it is a neat idea. There, it is basically a
> > string table, which maps names of classes and their members to
> > deobfuscated names (and the same for documentation, if I remember
> correct).
> >
> > I took that idea and made it a bit more flexible, and object oriented,
> > added mechanisms such as merging and inheritance of documentation,
> > combined it with a versioning system and took JSON as basic format.
> >
> > Then I've extracted available documentation from python API (thanks to
> > Ton's advice) and source code using doxygen into my documentation system
> > to fed it to my code generator. Both is not satisfying: Python API
> > actually provides documentation of RNA, which is quite similar to DNA
> > but still different, and the source code documentation is not addressed
> > to API developers, since DNA is not intended to be available to them, I
> > guess.
> >
> > Thus, I still have huge gaps in the documentation that have to be added
> > manually, somehow, but I can't provide it on my own (I'm already way off
> > track with this thing). To prevent wasting a lot of time of API
> > developers by forcing everyone of them to read blender source code to
> > figure out what they can actually do with the data, I'm planning to
> > setup some kind of community-driven source code documentation system
> > similar to a wiki, based on what I already have. My current idea is to
> > just host the JSON files in a separate repository on github so everybody
> > can easily share knowledge gained from studying blender source code by
> > sending in pull requests [2].
> >
> > When I mentioned that idea on a forum, someone pointed out, that others,
> > e.g. the C language guys, might be interested in the documentation as
> > well and I should discuss it with you for more elaborated input. Since
> > this is a bit of a longer story, and even non-blender developers may
> > want to throw in their thoughts, I decided to post it on the mailing
> list.
> >
> > So, what do you think about the idea? Are you interested to support it
> > from your side or even contribute to it? Or do you rather want to host
> > it yourself?
> >
> > The documentation could even be turned into wiki entries, if you want,
> > since it is in machine readable format.
> >
> >
> >
> >
> > Regards
> >   Holger Machens
> >
> >
> >
> > [1] http://homac.cakelab.org/projects/JavaBlend/
> > [2] https://help.github.com/articles/using-pull-requests/
> >
> > Ton seemed to think it was useful
> >
> > On Thu, Jan 21, 2016 at 12:52 AM, Owen Hogarth II <gurenchan at gmail.com>
> > wrote:
> >
> > > Jacob that's usually where it all ends up, stalled. They are trying to
> > > write a java parser for the python code when in all actuality if the
> core
> > > of blender was reorganized a bit, there would be no need for these
> types
> > of
> > > things. c is universal, blender is built on c and for ease of use the
> > > blender team decided to allow python scripts to allow more users to
> write
> > > useful tools which they do, no doubt about that.
> > >
> > > But for this type of work those things will only cause trouble, python
> to
> > > java or those topical fixes seem to work for a while until you run into
> > > memory issues, how does python manage memory vs java, do you want to
> deal
> > > with trying to maintain that?
> > >
> > > reorganizing the c code and then engines can speak directly to blender.
> > > There won't need to be separate code to maintain, it will be a part of
> > the
> > > main blender repo. You tell blender how to export models from c and
> your
> > > game engine interprets that data however you choose. Want blender to
> > > triangulate your mesh, write resources to a certain format, etc... That
> > can
> > > all be done from c but it's not easy to get to the way the current
> > blender
> > > code is organized.
> > >
> > > If you follow all those people who've attempted to do a topical fix
> they
> > > all get burnt out and sorta walk away or just disappear. The google
> code
> > > guy who did the android port, where did he go after the summer of code?
> > > Around 2011 there was a lot of excitement around that project and it
> just
> > > fizzled out. I am pretty sure he left one because time was up but also
> > > managing memory from two different languages with different memory
> models
> > > is not easy to solve. It's going to take looking at the problem in a
> > > different way and a little time to make serious changes. That's why I
> am
> > > looking for the community support.
> > >
> > > Best,
> > > Owen
> > >
> > > On Thu, Jan 21, 2016 at 4:42 PM, Jacob Merrill <
> > blueprintrandom1 at gmail.com
> > > >
> > > wrote:
> > >
> > > > sorry bad link -
> > > >
> > > >
> > > > I'm aiming to create a generic (any version) import/export of Blender
> > > > files for Java.
> > > >
> > > > So far, I've developed a tool which uses the type information from
> your
> > > > StructDNA to generate Java classes which serve as type safe facets to
> > > > access data from .blend files. Finally found a suitable concept for
> the
> > > > type mapping to Java (considering pointers, type casts and the dirty
> > > > stuff possible in C ;)).
> > > >
> > > > Now, I wanted to add a loader which actually just needs to organise
> the
> > > > incoming data, which comes in instances of the generated data model,
> in
> > > > some "Library". The same way as you do it in struct Main
> (BKE_main.h).
> > > > But I have to admit, that I've got lost in your code there - because
> > you
> > > > are scanning for blocks with IDs "LI" and "ID" which does not exist
> in
> > > > my reference file (v2.69).
> > > >
> > > > Are those not in all files or is that code for earlier file versions?
> > > > I've read the short intro in blendloader/internal/readfile.c which
> made
> > > > me confused looking at the content of my file.
> > > >
> > > > Can someone of you give me some (brief) hints on how it is supposed
> to
> > > > work?
> > > >
> > > >
> > > > Regards
> > > >   Holger
> > > > homac at strace.org
> > > >
> > > > On Thu, Jan 21, 2016 at 12:41 AM, Jacob Merrill <
> > > > blueprintrandom1 at gmail.com>
> > > > wrote:
> > > >
> > > > > I don't know if this is what your looking for
> > > > >
> > > > >
> > https://mail.google.com/mail/u/0/#search/add+on+java/1513f8f84cc1e25d
> > > > >
> > > > > On Thu, Jan 21, 2016 at 12:40 AM, Jacob Merrill <
> > > > > blueprintrandom1 at gmail.com> wrote:
> > > > >
> > > > >> I am not sure how the android blender players of the past handled
> > it,
> > > > >> but I know they were not 100% functional anyway,
> > > > >>
> > > > >> I did notice a email from ton about a Java backbone thing for
> > addons,
> > > > >>
> > > > >> I will dig.
> > > > >>
> > > > >
> > > > >
> > > > _______________________________________________
> > > > Bf-committers mailing list
> > > > Bf-committers at blender.org
> > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>