[Software] Bluerender, a rendering engine for LDD

[Sunder]

I've found a little bug in painting this armor.

Edited July 17, 2015 by Sunder

[___]

UPDATE:

@msx80

So I was finally able repair that "no more too dark glasses" side effect which makes all colors oversaturated/flat/not good...now it affects GLASS SHADERS only so any other type is intact, looks superb now!

I have realized something is not right with my fix when I was constantly getting unrealistic feeling from such renders, colors without depth, all overlighted/too saturated...and then I noticed you said the first time I presented my fix that it is maybe not good to applying that code change to everything, so I change/fix it with conditional if() and with added new method to every shader (shader.type()) that returns String of the shader type - by this custom moddification I was finally able making it work as it should!

BTW I also noticed some strange behaviour in some cases with my other src update for "noshadow" - for some strange reason in some situations where you place some additional object in a specific position my latest noshadow code makes areas without shadow where such shadows intersets, but strangely enough in exactly the same shadows intersection just in another placement all is fine...hmmmmm.

So I think I better go at this moment with further development of "logo-on-stud" instead...or even try to play and find some possible ways for brick seams? Gee, it's extremely hot here...I hate summer!

Edited July 17, 2015 by bublible

[Victor Imaginator]

So I think I better go at this moment with further development of "logo-on-stud" instead...or even try to play and find some possible ways for brick seams?

The question is - how BR uses 3d data from db.lif file. When model contains part number XXXX, BR search within db.lif for file named XXXX.g and get all the vertices and triangles from there. db.lif doens't contain any subprimitives. At least i don't find any. If BR will search for XXXX.obj prior to XXXX.g - problem will logo-on-studs and brick seams and softer endings of technic axles will solved quickly by redrawing all LDD parts)

[___]

If BR will search for XXXX.obj prior to XXXX.g - problem will logo-on-studs and brick seams and softer endings of technic axles will solved quickly by redrawing all LDD parts)

What???

[Victor Imaginator]

BR load some vertex and triangles data from files with ".g" extension contained within db.lif. If i replace file "32063.g" with "4519.g" - BR will render part 4519 instead of part 32063. And BR can process geometry not only from this strange ".g" format, but from ".obj" too. But when BR rendering lego parts - BR load this ".g" files. If BR will search not for only ".g", but for ".obj" too, when BR loading parts 3d data - we can make our own 3d models for all the parts. With seams, logo-on-studs, and more detailed e t.c.

Edited July 17, 2015 by Victor Imaginator

[___]

BR load some vertex and triangles data from files with ".g" extension contained within db.lif. If i replace file "32063.g" with "4519.g" - BR will render part 4519 instead of part 32063. And BR can process geometry not only from this strange ".g" format, but from ".obj" too. But when BR rendering lego parts - BR load this ".g" files. If BR will search not for only ".g", but for ".obj" too, when BR loading parts 3d data - we can make our own 3d models for all the parts. With seams, logo-on-studs, and more detailed e t.c.

Aha, got it and understood now.

Of course I know about the *.g files in db.lif - and it is not that easy as you said (just rewriting number on one *.g fro another *.g, there are also *.g1, *.g2 etc. files holding UV mapping and stuff...but I understood what you mean).

Well that is not bad thought and I personally like that principle BUT there are some known problems to this concept:

* as of now file-mesh object does not support UV map(s) therefore anything with them would not even load

* from what I said above also comes problem with bricks decorations: there would be no decors from .obj file bricks

* next: who would be willing to make every single brick .obj variant???

* I am not quite sure if the process of building mesh from *.g and *.obj is the same (number of vertices/triangles can be significantly higher and there were several occasions when @msx80 said that such an exponentional increase is a problem) cos if they are different there may be a lot of additional code update needed and as this part is in BR src that only @msx80 has access to who knows if he would be willing doing it?

[Victor Imaginator]

I will make most of common technic details. Maybe i will do more, i dont know yet. Decals it's a problem, but it can be solved somehow. Most of bricks with decals doesn't need to have advanced geometry - easy solution, but not final.

[___]

I will make most of common technic details. Maybe i will do more, i dont know yet. Decals it's a problem, but it can be solved somehow. Most of bricks with decals doesn't need to have advanced geometry - easy solution, but not final.

I have some other new idea of making brick seams in BR (ehm, not quite new rather the one I was suggesting before as no one actually tried to test it ), right now I am rendering something but later today I plan to try it and will post results if it would all go well...if it'd be of no use then do not await any renders.

Edited July 18, 2015 by bublible

[iceleftd]

Just curious - regarding extra polygons for seams and logo, is the concern the rendering time, the cost of modifying the parts at runtime, or both?

[___]

Just curious - regarding extra polygons for seams and logo, is the concern the rendering time, the cost of modifying the parts at runtime, or both?

I have no clue actually - the only one that ever came up with the concern was @msx80 (as he is the master mind behind the BR project), so I am curious as well...maybe much bigger memory usage?

Edited July 19, 2015 by bublible

[Victor Imaginator]

Extra polygons will cause extra memory usage, nothing more. I'm not 100% sure, it's just some kind of programmer's intuition) Of course BR may ask too much memory in case of extra complex scenes, and Java VM will deny it.

[msx80]

I've got some doubts about that. LDD somehow can simplify bricks: delets studs and inner tubes when they are covered with non-transparent bricks. Here is example.

That's interesting, never noticed it. I can assure the geometry files contain a flat triangle soup with no primitive or hierarchy (i actually wrote a parser for that :) ), so i can only conclude the information needed for such optimizations are stored in other files, or in still obscure areas of .g files.

Just curious - regarding extra polygons for seams and logo, is the concern the rendering time, the cost of modifying the parts at runtime, or both?

Extra polygons will cause extra memory usage, nothing more. I'm not 100% sure, it's just some kind of programmer's intuition) Of course BR may ask too much memory in case of extra complex scenes, and Java VM will deny it.

Memory usage is the main problem here. A single 3d logo is easily hundreds of extra vertex/triangles, which you have to multiply for each stud of each single brick in the scene. Sure Sunflow can handle multiple instances of the same geometry, but at some point it needs to make use of it. I'm pretty sure it will go OOM very fast :) The rendering will be slowed, but not that much as raytracers are usually good at handling high numbers of triangles. Extra loading time will be needed to analyze the bricks and find the studs, supposing i can craft a stud-finder algorithm, but this could be mitigated by storing the results on a database, either by the program at runtime or by me at "compile time". Now that i think of it, Blueprint has the same problem with the outline-finding algorithm, i could cache the result of it too. Uhm.

Bublible sorry i have to catch up with all your modifications, i haven't dedicated much time to bluereder lately. I have most of the mails to read too :)

PS an user was able to run Bluerender on a Mac and have it render correctly :) I'll see if i can craft some instructions and startup script for it.

[Victor Imaginator]

msx80, can you add an option to load bricks geometry not only from .g files, but from .obj too?

[iceleftd]

There has been some talk about lookaside objects (e.g., finding a decoration or object definition in a folder/jar/whatever that overrides the one in the LDD geometry), although that has been at least somewhat in the context of "can I supply my own object definition, maybe from LDraw?".

If it is real work to modify existing bricks in LDD every time, there is no real impediment to making a lazily-instantiated look-aside object structure where you apply bevels and logos and just save it in an alternate location. Objects then only need to be modified once, and only if they are used. You could save additional data to associate the modified object with the original object version. That would allow you to clear a cache entry if LDD's object definition changes.

The bigger question seems to be whether you can apply heuristics to make an algorithm that can correctly bevel and logo-ize arbitrary bricks on the fly. ldd2povray states "POV-Ray™ include files contain enhanced versions of brick geometries used by LDD." That would be worth looking into, I suppose. I do notice that ldd2povray allows you to vary the bevel size so presumably that's being done on the fly.

Speed is something we can fix, I think. Getting the right geometries is a different matter.

[___]

Bublible sorry i have to catch up with all your modifications, i haven't dedicated much time to bluereder lately. I have most of the mails to read too :)

OK, no problem...

msx80, can you add an option to load bricks geometry not only from .g files, but from .obj too?

Yesssss, I am second that!

[Garry_rocks]

There has been some talk about lookaside objects (e.g., finding a decoration or object definition in a folder/jar/whatever that overrides the one in the LDD geometry), although that has been at least somewhat in the context of "can I supply my own object definition, maybe from LDraw?".

If it is real work to modify existing bricks in LDD every time, there is no real impediment to making a lazily-instantiated look-aside object structure where you apply bevels and logos and just save it in an alternate location. Objects then only need to be modified once, and only if they are used. You could save additional data to associate the modified object with the original object version. That would allow you to clear a cache entry if LDD's object definition changes.

The bigger question seems to be whether you can apply heuristics to make an algorithm that can correctly bevel and logo-ize arbitrary bricks on the fly. ldd2povray states "POV-Ray™ include files contain enhanced versions of brick geometries used by LDD." That would be worth looking into, I suppose. I do notice that ldd2povray allows you to vary the bevel size so presumably that's being done on the fly.

Speed is something we can fix, I think. Getting the right geometries is a different matter.

I had exactly the same thought: replacing some poorly modeled bricks from LDD with some more precise models from other libraries like those from LDraw (I only know about LGEO, not sure if it'll do here). I don't think that every single part needs a replacement, but those round parts and curved slopes are the first thing that gives the render away every time. From what I read, parts with segmented curves should take longer to render than those with continuous curves.

As for the bevels and logo on studs in LDD2POV-Ray, I've heard it uses some "connectivity data" from .lxf file to place that logo and indeed has some algorithm to add bevels "on the fly".

Ah yeah, one more thing! There is a parameter in LDD2POV-Ray "All bevels/Only visible bevels", so I guess there is a way to get that info about "simplified" bricks (like those Sunder mentioned above) from .lxf too.

Edited July 21, 2015 by Garry_rocks

[___]

Replacing LDD bricks with LDRAW/LGEO ones during render in BR - actually this can be done rather easily I guess, but only @msx80 can do it as the src code is part of his BR src (not SF)...basically he needs to make LDRAW parser for BR (which he already said he can do as he originally came from LDRAW), finentuning it (scaling + xyz offset - unfortunatelly this would needed to be done for every brick separatelly so it would be a lot of time consuming tiddious work) and then only replace those between one another (LDD -> LGEO) - I know this can be done as I basically did this with crater baseplate with success...

Of course there would be some exceptions (a few) like flexible LDD parts: those would stay original LDD and intact...ending up mixing those two software worlds into one output (once again: such mixing can be done as I already did it myself although only with one particular brick! )

Edited July 21, 2015 by bublible

[anothergol]

Bluerender definitely has replaced LDD to POVRay here. I think it just looks better because the default choice of lighting is better. Even though both tools don't look that great at normal precision, I always render 2 or 4x bigger.

(edit: ah, hadn't noticed the aa setting, it's an oversampling factor? can't find what the values are for, but 4 4 seems to improve a lot. I'm guessing it's not X & Y oversampling factors, as it defaults to 0 1. I'm guessing the second value is the oversampling factor, and the first a coverage method or something?)

I'd like to reiterate my request for animation, because this is really something that's not possible (in less than 1 year of render time) using POVRay, while BlueRender would do that in half a day at worst.

A simple 360 rotation around the vertical axis would allow presenting stuff, like I tried to do here using a turntable, but it's horrible to do in the analog world, whatever can go wrong, goes wrong:

Edited July 21, 2015 by anothergol

[___]

A simple 360 rotation around the vertical axis would allow presenting stuff, like I tried to do here using a turntable...

Yea I agree that such a simple Y axis rotation camera animation add-on fro BR would be great - I am all for that!

There could be just 2 parameters:

1. SPEED

2. DIRECTION OF ROTATION

[iceleftd]

Animation now? I think we all need to chip in for some coffee and pizza for poor msx80, considering all the work we're piling on him!

[___]

Animation now? I think we all need to chip in for some coffee and pizza for poor msx80, considering all the work we're piling on him!

Does not need to be done right now cos other things are surely much more important of course but just as a next "thing to consider" it looks very fine I guess.

[Victor Imaginator]

I make some tests and can conclude now:

SunFlow oversampling ("sample XX" parameter) does work, but effect is barely noticed. Rendering time inceased by XX times.

SunFlow antialiasing does work, and effect is nice, but far from ideal. Result is blurry and rendering time increased too much.

Rendering picture oversized and using photoshop to resize looks much better than any SunFlow methods.

Notice thin black rings around wheel axles at last picture. It's a geometry, and manual 16x oversampling show it, while SunFlow doesn't.

[aeralure]

PS an user was able to run Bluerender on a Mac and have it render correctly :) I'll see if i can craft some instructions and startup script for it.

Please!

[msx80]

msx80, can you add an option to load bricks geometry not only from .g files, but from .obj too?

I'd have to write/find a parser but i guess it's not hard.

There has been some talk about lookaside objects (e.g., finding a decoration or object definition in a folder/jar/whatever that overrides the one in the LDD geometry), although that has been at least somewhat in the context of "can I supply my own object definition, maybe from LDraw?".

LDraw geometries are no better than LDD. They have no bevel either and they're very similar in all respect, the only thing they have is that, thanks to his hierarchical nature, it's easy to replace curved primitives with higher quality ones. But they have different size, origin and orientation than LDD making replacement a mess.

The bigger question seems to be whether you can apply heuristics to make an algorithm that can correctly bevel and logo-ize arbitrary bricks on the fly. ldd2povray states "POV-Ray™ include files contain enhanced versions of brick geometries used by LDD." That would be worth looking into, I suppose. I do notice that ldd2povray allows you to vary the bevel size so presumably that's being done on the fly.

Yes, the biggest problem is the algorithm, once you have it, you can apply it on the fly or cache the results locally.

Bluerender definitely has replaced LDD to POVRay here. I think it just looks better because the default choice of lighting is better. Even though both tools don't look that great at normal precision, I always render 2 or 4x bigger.

(edit: ah, hadn't noticed the aa setting, it's an oversampling factor? can't find what the values are for, but 4 4 seems to improve a lot. I'm guessing it's not X & Y oversampling factors, as it defaults to 0 1. I'm guessing the second value is the oversampling factor, and the first a coverage method or something?)

I'd like to reiterate my request for animation, because this is really something that's not possible (in less than 1 year of render time) using POVRay, while BlueRender would do that in half a day at worst.

A simple 360 rotation around the vertical axis would allow presenting stuff, like I tried to do here using a turntable, but it's horrible to do in the analog world, whatever can go wrong, goes wrong:

In the PDF there's some information, i'm not sure what they're for either.

As for the animation, i think i can add it, it would be useful for me too. But only simple 360 rotations as you say, nothing fancy :)

Animation now? I think we all need to chip in for some coffee and pizza for poor msx80, considering all the work we're piling on him!

coffee and pizza are always welcome :P As for the pile of work, i'm searching for some free online issue tracker so all of you can enter and discuss things, but still can't find something good.

Please!

As for the Mac, this is the reported way to make it work (thanks go to Jackalope):

• Remove all java installations
  
• Install Java, but not from Oracle, from Homebrew instead. What's HomeBrew? I've no idea, but you can try following these instruction.
  
• Open a command prompt/shell/terminal, cd to the folder where you unzipped Bluerender
  
• Enter the following command: java -cp "bin/*" bluerender.BlueRender
  
• If the program manage to start, it will ask you to locate the db.lif file, you should find it here: /Users/USERNAME/Library/Application Support/LEGO Company/LEGO Digital Designer/db.lif
  
• Render!
  

Let me know if it works!

[___]

I'd have to write/find a parser but i guess it's not hard.

Oh, Nicola, c'mon - there already is .obj parser in SunFlow, that is of course the reason I am able loading .obj files, right?

Or did I once again do not understand something?

And the priority should be like:

if there is an *.obj version of the brick use that one, if there is none use standard LDD brick from *.lif

+ I was looking into SF code why it does not support UV mapping in .obj files (file-mesh code compared to generic-mesh code which does support UV mapping) - if you try to open .obj with UV map it does not even load it, and it really looks like they simply left it out, so it should not be a problem to include the missing part into the corresponding file-mesh code...if I find myself a time I can do it, I guess.

Edited July 22, 2015 by bublible