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" <[email protected]> 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 <[email protected] > > > 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 <[email protected]> > > 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 < > > [email protected] > > > > > > > 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 > > > > [email protected] > > > > > > > > On Thu, Jan 21, 2016 at 12:41 AM, Jacob Merrill < > > > > [email protected]> > > > > 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 < > > > > > [email protected]> 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 > > > > [email protected] > > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > _______________________________________________ > > > Bf-committers mailing list > > > [email protected] > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
