[Bf-committers] blender as ui for game engine

[Owen Hogarth II]

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
>