[Software] Bluerender, a rendering engine for LDD

[iceleftd]

What is this new software ? :P :P

PS you can preview the release here, i'll update the page later... so much to do today :(

Thanks for the sneak peak! <salivating>

P.S. you should update the readme with a list of changes for each version. See! Even more to do today! :P

[___]

What is this new software ? :P :P

PS you can preview the release here, i'll update the page later... so much to do today :(

Gee, sorry, I meant BlueRender, of course.

Gonna play with the new version now...thanx a lot!

[___]

v2 problems:

• IBL Light do not work
  
• .png with trans bg still renders as opaque white (high quality 32bit with full range colors incl. alpha channel, not those common 8bit with limited number of colors)
  
• for some reason v2 takes much longer to start rendering compared to v1
  

Edited June 3, 2015 by bublible

[iceleftd]

I found this interesting behavior with one of my models (using either 0.0.1 or 0.0.2). The upper image uses the default settings for the plane and the model appears to be partially submerged in the plane. I'm guessing there is some problem with figuring out the default plane location.

Changing the shader value ("p 0 -.3 0") seems to correct the problem, as shown in the lower image. If I didn't have a baseplate on the bottom, though I might not have caught this issue.

Floor render problem by iceleftd, on Flickr

Edited June 3, 2015 by iceleftd

[___]

I found this interesting behavior with one of my models (using either 0.0.1 or 0.0.2). The upper image uses the default settings for the plane and the model appears to be partially submerged in the plane. I'm guessing there is some problem with figuring out the default plane location.

Changing the shader value ("p 0 -.3 0") seems to correct the problem, as shown in the lower image. If I didn't have a baseplate on the bottom, though I might not have caught this issue.

Floor render problem by iceleftd, on Flickr

No, the problem is actually in your .lxf file where you probably added some brick to the lower most one so the whole scene in LDD got lower than y0 (that is into negative Y) but you would not see it until you render it or until you go to LDd open the .lxf CTRL+A (selecting all your bricks of the model) and slightly move them together a tiny bit - that way your LDD model got back so the lowest brick will be positioned correctly to y0

Edited June 3, 2015 by bublible

[___]

SUGGESTIONS:

* missing LDD decorations - when there is missing decoration in LDD (ehm, for whatever reason...as it is considered illegal on this forum I cannot talk about it publicly here but can explain it to you over PM if you'd be interested,no problem ) rendering stops, if it is possible it should simply continue without any decoration on the respective brick (this way it goes very well in POVRAY) - now the practice with BlueRender is such that it just stops with error popup.

Edited June 3, 2015 by bublible

[iceleftd]

No, the problem is actually in your .lxf file where you probably added some brick to the lower most one so the whole scene in LDD got lower than y0 (that is into negative Y) but you would not see it until you render it or until you go to LDd open the .lxf CTRL+A (selecting all your bricks of the model) and slightly move them together a tiny bit - that way your LDD model got back so the lowest brick will be positioned correctly to y0

But I thought that adding a lower brick moved the floor in LDD so the entire model is always at or above y0. Is that wrong? Moving the entire model and resaving did seem to fix the problem, but isn't that some sort of bug in LDD? I can easily imagine not noticing that little of a difference when rendering if the base is made of bricks and that worries me.

[___]

But I thought that adding a lower brick moved the floor in LDD so the entire model is always at or above y0. Is that wrong? Moving the entire model and resaving did seem to fix the problem, but isn't that some sort of bug in LDD? I can easily imagine not noticing that little of a difference when rendering if the base is made of bricks and that worries me.

Firstly: being glad my advice helped you

Secondly: I do not know if it can be considered as a LDD bug (but probably it is), anyway I am dealing with this LDD behaviour from the first moment I started working with it (like 4 years ago), maybe you could post it in LDD bugs subforum?

Edited June 3, 2015 by bublible

[iceleftd]

Firstly: being glad my advice helped you

Secondly: I do not know if it can be considered as a LDD bug (but probably it is), anyway I am dealing with this LDD behaviour from the first moment I started working with it (like 4 years ago), maybe you could post it in LDD bugs subforum?

Thanks for the help! It might just be easier and quicker to have BlueRender detect the problem and correct it when loading the file.

[msx80]

SUGGESTIONS:

* correct lights positioning - it should be positioned from BlueRay camera point-of-view, not from LDD original front side, cos then when you have your camera look lets say from behind and set your lights has to be "-10 0 0" then it actually move them in exact opposite direction to "10 0 0" cos it has locked its XYZ axes to front LDD view still which is wrong + of course not even saying they are not straight opposite values but it rather add some more degrees to it so it is in fact absolutely not possible to achieve quite simple lights placement as you may see I guess basically something similar you did with the camera transformation using %LDDCAMERA% but this time it should be upon actual BlueRender already transformed camera position where light "0 0 0" = transformed camera "0 0 0" position...and I think this one feature is the most important for now

* simple color gradient shader - allowing us having smooth color transition at least between two defined colors, that'd be great...and I know you can do it as you already proved your almost deity-like...or something

* rotation for IBL Lights - for correction of alignment of the HDR angle for such cases where simple "flipping" does not help

Basically you're suggesting making the sun position relative to the camera instead of absolute. I already tought of that and i concord think it's necessary.

Deity like no less :D Thank you! But you want gradient for the background or really as a shader to attach to plane and bricks etc?

v2 problems:

• IBL Light do not work
  
• .png with trans bg still renders as opaque white (high quality 32bit with full range colors incl. alpha channel, not those common 8bit with limited number of colors)
  
• for some reason v2 takes much longer to start rendering compared to v1
  

You mean that a file with IBL light was working in 0001 and not working in 0002? That's strange. Could you post a comparison?

If you can pass me the offending png i can give it a try.

How much slower? Can you pinpoint the step that's taking more? The startup is almost the same, strange it's slower.

But I thought that adding a lower brick moved the floor in LDD so the entire model is always at or above y0. Is that wrong? Moving the entire model and resaving did seem to fix the problem, but isn't that some sort of bug in LDD? I can easily imagine not noticing that little of a difference when rendering if the base is made of bricks and that worries me.

No actually in LDD you can put parts below zero, they just push the ground lower. In Bluerender the ground is fixed at 0, you have to change it manually as you already figured out. Maybe in future it would be automatic.

[___]

Basically you're suggesting making the sun position relative to the camera instead of absolute. I already tought of that and i concord think it's necessary.

Almost: NOT THE SUN, cos like in reality sun is still on its place independent of your camera position, I am talking specificslly about SPHERICAL and DIRECTIONAL lights only: those needs to correspond to actual camera view so when I want move them to right side of the camera they have to be on right and not on the right side of the front side of the LDD plane

Deity like no less :D Thank you! But you want gradient for the background or really as a shader to attach to plane and bricks etc?

Sorry, I was simply smashed by the fact v2 is here so I go nuts for a while trying to be funny...

Shader as I mean it as a counter part to normal color and textures options we already have, such shader can be then applied to any mesh, so if I wanted infi ite background I would make L ramp mesh and apply thet gradient and yet I can use it as a surface on anything else, therefore mainly SHADER, yes ...but if you can also make some kind og gradient background besides the gradient shader then please go for it as well!

You mean that a file with IBL light was working in 0001 and not working in 0002? That's strange. Could you post a comparison?

If you can pass me the offending png i can give it a try.

As for the IBL Light: strangely enough for some reason it works now (maybe I had some errors in my script in .sc)

And as for the .png problem, here it is for you to test it yourself:

How much slower? Can you pinpoint the step that's taking more? The startup is almost the same, strange it's slower.

Well, when I have all set and hit RENDER button it seems like the parser fights with every single brick like 0,5 seconds so the time to actual pop up of the rendering image window is quite long like 1 minute with bigger model whereas in v1 it was like "swooooosh!", almost immediately...I do not know maybe you left in you code some part that is not necessirily repetitive with every brick and that part slowing it down?

No actually in LDD you can put parts below zero, they just push the ground lower. In Bluerender the ground is fixed at 0, you have to change it manually as you already figured out. Maybe in future it would be automatic.

Now that is not tge case: when you have such .lxf where its base was lowered to negative Y and you move your camera in LDD quite to the bottom so you look at your model from stright front side you will see MOST OF THE MODEL HANGS IN THE AIR and just the lowest brick sits on the plane, so I rather suggest the trick I write in my post above that fix it. But many times you even need to cut (CTRL+C) or even delete for a second that lowest brick so all your model got down to the y0 plane and then bring the previously cutted/deleted brick back

[msx80]

Almost: NOT THE SUN, cos like in reality sun is still on its place independent of your camera position, I am talking specificslly about SPHERICAL and DIRECTIONAL lights only: those needs to correspond to actual camera view so when I want move them to right side of the camera they have to be on right and not on the right side of the front side of the LDD plane

Sorry, I was simply smashed by the fact v2 is here so I go nuts for a while trying to be funny...

Shader as I mean it as a counter part to normal color and textures options we already have, such shader can be then applied to any mesh, so if I wanted infi ite background I would make L ramp mesh and apply thet gradient and yet I can use it as a surface on anything else, therefore mainly SHADER, yes ...but if you can also make some kind og gradient background besides the gradient shader then please go for it as well!

As for the IBL Light: strangely enough for some reason it works now (maybe I had some errors in my script in .sc)

And as for the .png problem, here it is for you to test it yourself:

Well, when I have all set and hit RENDER button it seems like the parser fights with every single brick like 0,5 seconds so the time to actual pop up of the rendering image window is quite long like 1 minute with bigger model whereas in v1 it was like "swooooosh!", almost immediately...I do not know maybe you left in you code some part that is not necessirily repetitive with every brick and that part slowing it down?

Now that is not tge case: when you have such .lxf where its base was lowered to negative Y and you move your camera in LDD quite to the bottom so you look at your model from stright front side you will see MOST OF THE MODEL HANGS IN THE AIR and just the lowest brick sits on the plane, so I rather suggest the trick I write in my post above that fix it. But many times you even need to cut (CTRL+C) or even delete for a second that lowest brick so all your model got down to the y0 plane and then bring the previously cutted/deleted brick back

The PNG should be a square, and possibly it may have to be a power of two, ie 128x128, 256x256, 512x512 etc.

About the loading time, i'll take a look. I have a couple of ideas to make it quicker anyway.

Thanks :)

[iceleftd]

Another observation:

Doing a higher-res image, I was averaging about 65% CPU (8 core machine). This is in contrast to POV-Ray which runs all cores at 100%.

After realizing I was running 32-bit Java, I upgraded to the 64-bit JDK. Now all cores run at 100%. Thought you all might find that interesting.

[___]

The PNG should be a square, and possibly it may have to be a power of two, ie 128x128, 256x256, 512x512 etc.

Ee, no, not this one, cos this is my file for my technique of "trans polygon decors" in POVRAY

If it'd be for LDD decors change then it should be exactly 128x128 as that is the decors size from db.lif

Anyway what have its size to do with the fact the transparency still do not work? Or am I missing something?

BTW I tested also this kind of size with LDD replacement decors and all was working fine so...

Did its transparency work for you? If so could you please show me your exact syntax of implementation (that is mesh object code + shader code)?

Another observation:

Doing a higher-res image, I was averaging about 65% CPU (8 core machine). This is in contrast to POV-Ray which runs all cores at 100%.

After realizing I was running 32-bit Java, I upgraded to the 64-bit JDK. Now all cores run at 100%. Thought you all might find that interesting.

If you are on 64bit OS shouldn't that Java installer select its 64bit version automatically by default?

Edited June 3, 2015 by bublible

[msx80]

i tested it after cropping at 128x128 and it worked, i didn't tested before cropping

[___]

i tested it after cropping at 128x128 and it worked, i didn't tested before cropping

Interesting enough, so please could you show me your exact syntax of implementation (that is mesh object code + shader code)?

Better said: made just simple rectangle (4 sides if you do not know ...not box, just 2D rectangle) and try to apply it there cos that is how I am doing it

Actualy this the block of my code:

#
shader
{
   name cs
   type diffuse
   texture Z:/_LEGO_/__MOC__/691518/2466p90.png
}

#
object
{
   shader cs
   transform
   {
       scale 5 5 5 5
       translate 0 0 5
       %rotatex 90
   }
   type generic-mesh
   name "Plane"
   points 4
   0 0 0
   0 1 0
   1 1 0
   1 0 0
   triangles 2
   0 3 2
   0 2 1
   normals none
   uvs vertex
   0 0
   0 1
   1 1
   1 0
}

And here how it actually look:

Edited June 3, 2015 by bublible

[msx80]

ok i got it: i havent' implemented texture alpha for shaders, those one remained as they were. I implemented a texture attribute for instances. This way i can have a normal shader and apply a texture to the specific object without having a proliferation of materials (beside solving other problems). So you can use a standard material (like mat1) and apply whatever texture. The syntax is as follow:

object
{
    noinstance
    type generic-mesh
    name "Plane"
    points 4
    0 0 0
    0 1 0
    1 1 0
    1 0 0
    triangles 2
    0 3 2
    0 2 1
    normals none
    uvs vertex
    0 0
    0 1
    1 1
    1 0
}
instance
{
    name PlaneInstance
    geometry Plane

    transform
    {
            scale 5 5 5 5
            translate 0 0 5
            %rotatex 90
    }
    texture c:\path\face.png
    shader mat37
}

The result is this:

Notice that object has a "noistance" attribute, it says "don't generate an object, simply memorize the geometry and let me reuse it in separated "instances" as many time as i want withour repeating all vertex etc"

you can try that code with your original non-square texture, it may work. But note that in general texture should always be squared and power of two, to work interoperably with other softwares. Opengl for example require that.

Edited June 4, 2015 by msx80

[___]

ok i got it: i havent' implemented texture alpha for shaders, those one remained as they were. I implemented a texture attribute for instances. This way i can have a normal shader and apply a texture to the specific object without having a proliferation of materials (beside solving other problems). So you can use a standard material (like mat1) and apply whatever texture. The syntax is as follow:

object
{
noinstance
type generic-mesh
name "Plane"
points 4
0 0 0
0 1 0
1 1 0
1 0 0
triangles 2
0 3 2
0 2 1
normals none
uvs vertex
0 0
0 1
1 1
1 0
}
instance
{
name PlaneInstance
geometry Plane

transform
{
scale 5 5 5 5
translate 0 0 5
%rotatex 90
}
texture c:\path\face.png
shader mat37
}

Notice that object has a "noistance" attribute, it says "don't generate an object, simply memorize the geometry and let me reuse it in separated "instances" as many time as i want withour repeating all vertex etc"

Aha, underestood - gonna try it right away...

you can try that code with your original non-square texture, it may work. But note that in general texture should always be squared and power of two, to work interoperably with other softwares. Opengl for example require that.

Did not know that as I was not doing some universally usable ones, just for my needs where I need approximate size of the target shape (be it rectangle or any other) to lay my design right and if it were for LDD only then I hard resized it to strict deformated 128x128 but of course that would work in everywhere just like you said BUT the case is I wanted to avoid permanent resizing back to its right dimensions everytime I want change something in the design or graphic

[___]

That does not work at all, all I got is completely black rectangle

Could it be that you have some new code in the BR version you are testing it yourself that is not in the latest v2...maybe?

Besides if there is need to also have a shader applied on the instance how it can have transparent bg when there is no option how to make a shader color value transparent?

Edited June 4, 2015 by bublible

[msx80]

That does not work at all, all I got is completely black rectangle

Are you sure you're putting the instance AFTER the definition of the shader you're using? if you're using standard materials, you have to place the code i wrote AFTER them.

Besides if there is need to also have a shader applied on the instance how it can have transparent bg when there is no option how to make a shader color value transparent?

Uh? If you mean applying textures on transparent objects, it's not possible.

[___]

Are you sure you're putting the instance AFTER the definition of the shader you're using? if you're using standard materials, you have to place the code i wrote AFTER them.

Yes, of course - I applied it exactly as in your preview...

Uh? If you mean applying textures on transparent objects, it's not possible.

Oh, that is not good cos then I am done with my "polygon trans decor" trick...

[___]

OK, so now it works (thanx @ msx80) BUT not with the glass shader

+ also according to SunFlow PDF there should also be support in "trace-depths{}" statement for attribute "trans" (which is trans 10 be default so that said THERE DEFFINITELY SHOULD BE COMPLETE TRANSPARENCY POSSIBLE in SunFlow, right? ) but when I set it there nothing is rendered at all...

EDIT:

I just realized they are only nr. of bounces not the amount of transparency, ah...

This exploration is so exciting, every minute I found something new even things that was said do not exist like complete mesh/shader transparency...well, there is one like this:

shader
{
   name trns
   type glass
   color 1 1 1
   eta 1
}

This way you achieve completely transparent object...ehm, the only disadvantage is that it still cast shadows, except that it seems to be OK (@msx80: could you also implement shadow transparency for completely transparent object like this, please? )

I guess simple programmatic solution would be something like this:

if((shader.type == "glass") && (shader.glass.color == 1 1 1) && (shader.glass.eta == 1))
{
   shadows.casting = false;
}

Edited June 4, 2015 by bublible

[___]

I guess simple programmatic solution would be something like this:

if((shader.type == "glass") && (shader.glass.color == 1 1 1) && (shader.glass.eta == 1))
{
   shadows.casting = false;
}

Or even better - to somewhat standardizing such behavior - let's add 3 new attributes for shader or object inspired in POVRAY like:

shader
{
   noshadow
   noreflections
   noimage
   ...
}

object
{
   noshadow
   noreflections
   noimage
   ...
}

I guess they are selfexplanatory, anyway:

noshadow - shader/object does not cast shadow

noreflections - shader/object does not cast its reflections on other objects

noimage - shader/object is casting shadow and reflections (unless previous attributes are present) but the object itself is not visible

Edited June 4, 2015 by bublible

[iceleftd]

Nick - Despite all your warnings about imminent software explosions, until now I never had a problem with the working of Bluerender (unless I screwed up the scene file).

Today, I tried to render a model and got this:

BRICK Part 431 6111 (BRICK 1X10) Colors:194
BRICK Part 444 3008 (BRICK 1X8) Colors:194
BRICK Part 532 58124 (FUNC. PLUG TOP) Colors:199, 26
java.lang.ArrayIndexOutOfBoundsException: 2
 at bluerender.BlueRender.a(Unknown Source)
 at bluerender.BlueRender.b(Unknown Source)
 at bluerender.BlueRender.c(Unknown Source)
 at bluerender.BlueRender$$Lambda$175/67551355.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)

How do you want to solve these kinds of problems? The best way, I suppose, would be to send you the LXF file privately for you to test with yourself in the debugger.

I really wish this was a collaborative build - I'm itching to get into the code!

P.S. I agree with bublible that the render preprocessing is much slower in V2. Makes me wish for caching even more.

Edited June 4, 2015 by iceleftd

[msx80]

OK, so now it works (thanx @ msx80) BUT not with the glass shader

+ also according to SunFlow PDF there should also be support in "trace-depths{}" statement for attribute "trans" (which is trans 10 be default so that said THERE DEFFINITELY SHOULD BE COMPLETE TRANSPARENCY POSSIBLE in SunFlow, right? ) but when I set it there nothing is rendered at all...

EDIT:

I just realized they are only nr. of bounces not the amount of transparency, ah...

This exploration is so exciting, every minute I found something new even things that was said do not exist like complete mesh/shader transparency...well, there is one like this:

shader
{
name trns
type glass
color 1 1 1
eta 1
}

This way you achieve completely transparent object...ehm, the only disadvantage is that it still cast shadows, except that it seems to be OK (@msx80: could you also implement shadow transparency for completely transparent object like this, please? )

I guess simple programmatic solution would be something like this:

if((shader.type == "glass") && (shader.glass.color == 1 1 1) && (shader.glass.eta == 1))
{
shadows.casting = false;
}

Uhm i'm pretty sure you don't have an exact idea of how shadows work in a raytracer :P Or how complex the code behind it is :)

I'm sorry but i'm not picking up the development of sunflow. I did the minimal on texture alpha support just becouse it was necessary and becouse it was a clean operation, but i'm not expanding it :) I might make some tests on texturized glass but that's all, i don't promise any result :) Sorry to disappoint you!

Nick - Despite all your warnings about imminent software explosions, until now I never had a problem with the working of Bluerender (unless I screwed up the scene file).

Today, I tried to render a model and got this:

BRICK Part 431 6111 (BRICK 1X10) Colors:194
BRICK Part 444 3008 (BRICK 1X8) Colors:194
BRICK Part 532 58124 (FUNC. PLUG TOP) Colors:199, 26
java.lang.ArrayIndexOutOfBoundsException: 2
 at bluerender.BlueRender.a(Unknown Source)
 at bluerender.BlueRender.b(Unknown Source)
 at bluerender.BlueRender.c(Unknown Source)
 at bluerender.BlueRender$$Lambda$175/67551355.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)

How do you want to solve these kinds of problems? The best way, I suppose, would be to send you the LXF file privately for you to test with yourself in the debugger.

I really wish this was a collaborative build - I'm itching to get into the code!

P.S. I agree with bublible that the render preprocessing is much slower in V2. Makes me wish for caching even more.

Glad to hear your experience was explosion free :) About the error, yes you could send me the problematic lxf and i'll give it a go in debug. But first try this: i noticed that some similar errors happened to me with very old lxf files (made with old version of LDD). The solution was opening them with (current) LDD and re-saving. Some times it corrected the issue. Might help if this is your case too.

About speed: is it in the proper rendering or in the "loading" phase (before opening the image window)? The rendering should be exacly the same. The loading maybe slowed a bit but i'm working on it right now. I'm switching to parallel loading, should use all the core and be about twice as fast (which will go into blueprint too!)