[Software] Bluerender, a rendering engine for LDD

[msx80]

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?

Of course there is, but first of all it's not a good parser as you noticed (no UV support and probably other shortcomings) and most importantly it's not where it needs to be: the code that parses ldd data does not depend on Sunflow and is not exclusive to Bluerender (it's used by Blueprint in the first place). It's this code that has to handle the obj files, the same way it handle alternative decorations.

[___]

Of course there is, but first of all it's not a good parser as you noticed (no UV support and probably other shortcomings) and most importantly it's not where it needs to be: the code that parses ldd data does not depend on Sunflow and is not exclusive to Bluerender (it's used by Blueprint in the first place). It's this code that has to handle the obj files, the same way it handle alternative decorations.

Yea, I know about the lack of UV mappings but as I said in my previous message here it can be done quite easily by copying and maybe slightly modifying generic-mesh UV part + I understand that the actual brick manipulation is not made in SF but in your src of BR which only you have access to, so please go for it as that would be most probably the most viable solution to our seams/logo-on-stud "problem" (that is anyone who has this skill of 3D can make a brick and then later on we can make kind of official...ehm, BR included .obj bricks that looks the best from them all, what do you think of?).

Edited July 22, 2015 by bublible

[msx80]

Yea, I know about the lack of UV mappings but as I said in my previous message here it can be done quite easily by copying and maybe slightly modifying generic-mesh UV part + I understand that the actual brick manipulation is not made in SF but in your src of BR which only you have access to, so please go for it as that would be most probably the most viable solution to our seams/logo-on-stud "problem" (that is anyone who has this skill of 3D can make a brick and then later on we can make kind of official...ehm, BR included .obj bricks that looks the best from them all, what do you think of?).

Yes the idea of having a secondary library with customized geometries is nice. It would teoretically solve a lot of problems (bevels (given someone can do them), logos, uv mappings where it misses, etc), but it will also open a millions other problems (not last breaking ldd eula).

Anyway, i can still implement obj parsing (since it looks like LDD does it) then you guys can try and use it for whatever you want :)

PS does anybody have some obj files of some bricks to test ?

[___]

Yes the idea of having a secondary library with customized geometries is nice. It would teoretically solve a lot of problems (bevels (given someone can do them), logos, uv mappings where it misses, etc), but it will also open a millions other problems (not last breaking ldd eula).

Anyway, i can still implement obj parsing (since it looks like LDD does it) then you guys can try and use it for whatever you want :)

PS does anybody have some obj files of some bricks to test ?

How it can break LDD Eula? You do not modify LDD bricks nor its geometry as you can make those .obj bricks from LDRAW library...? Using just the position coordinates do not break anything from LDD that would be illegal cos then you come to some absurd stuff like clear polygon with my own decor being positioned into the coordinates of some concrete brick would be taken as illegal...absurd, isn't it?

EDIT:

+ I would also like to add that actually in fact there even is not any Blender importer for LDD but on the other hand there is LDRAW importer for it (and that is what I am using, so there is not option how to get LDD file directly into Blender therefore suggesting obj bricks made in Blender would be designed from ,lxf is not quite true I guess). And YES you can combine/replace actual LDD bricks with LDRAW ones during render (so once again: not in LDD - we are using just the position matrix of the respecitve bricks for BlueRender) but as you said one needs to finetuning its size (and maybe its position too) first.

Edited July 22, 2015 by bublible

[Garry_rocks]

I did some test renders using different types of lighting. All the alternative light sources were present in the initial scene file by msx80, so my own intrusion was minimal.

Here's what I got with default (sunsky) lighting:

The next one was using a directional light source. Looks kinda like POV-Ray with really low settings to me.

And the last one was using that example of spherical light. And this one looks exactly like POV-Ray with no radiosity. Even those reflections of the light source are very similar.

What was my point here? I tried to show that both SunFlow and POV-Ray have very close results when the settings are close. All of the difference is in the default settings that LDD2POV-Ray and Bluerender are using. The Bluerender has much more appealing default parameters, its materials are less shiny and reflective. This makes the images created in Bluerender look better than those from LDD2POV-Ray. And yet they don't look very photorealistic, not only because of the lack of bevels and logo on studs, but because of their cartoon-like bright palette. This is at least how I see it. I quite like Bluerender though, mixing it with low-quality POV-Ray renders gives really nice results and saves time.

[___]

I did some test renders using different types of lighting. All the alternative light sources were present in the initial scene file by msx80, so my own intrusion was minimal.

Here's what I got with default (sunsky) lighting:

The next one was using a directional light source. Looks kinda like POV-Ray with really low settings to me.

And the last one was using that example of spherical light. And this one looks exactly like POV-Ray with no radiosity. Even those reflections of the light source are very similar.

What was my point here? I tried to show that both SunFlow and POV-Ray have very close results when the settings are close. All of the difference is in the default settings that LDD2POV-Ray and Bluerender are using. The Bluerender has much more appealing default parameters, its materials are less shiny and reflective. This makes the images created in Bluerender look better than those from LDD2POV-Ray. And yet they don't look very photorealistic, not only because of the lack of bevels and logo on studs, but because of their cartoon-like bright palette. This is at least how I see it. I quite like Bluerender though, mixing it with low-quality POV-Ray renders gives really nice results and saves time.

Please take no offence from what I will say now as I do not mean it like that BUT I have to tell you that besides those known factors you mentioned yourself (no brick seams and no logo-on-stud at the moment...tho things are changing from each day and once @msx80 implements what we were talking about today - .obj brick importer - those become problems of tge past instantly ) its more like you simply do not know how to light and set up your scene properly thus getting those "cartoonish" look - it needs more than trying some of the default lights that are there in scene.sc made by @msx80

If one make scene lights and setup properly he gets quite realistic scene resembling those LEGO photos of their sets from their 80's catalogues... I will show you what I mean later today or tomorrow if you will as now I have not much time...

Also POVRay has much more trouble with right glass feeling (at least with trans dark blue which I am using), whereas BR makes it right with "a flick of a wrist" in contrary not even saying how extremely quick it is! + to achieve such realness as BR in POVRay you have to go up with Q settings pretty high which again rising up time needed for such render and yet it would look somewhat "surreal"/overrealistic - all in all BR fits many times better to me than POVRay when it comes to rendering my MOC Space stuff.

SunFlow is quite a hidden gem @msx80 discovered for us and he deserves many big thanx on and on and on...you know.

Edited July 22, 2015 by bublible

[Garry_rocks]

Please take no offence from what I will say now as I do not mean it like that BUT I have to tell you that besides those known factors you mentioned yourself (no brick seams and no logo-on-stud at the moment...tho things are changing from each day and once @msx80 implements what we were talking about today - .obj brick importer - those become problems of tge past instantly ) its more like you simply do not know how to light and set up your scene properly thus getting those "cartoonish" look - it needs more than trying some of the default lights that are there in scene.sc made by @msx80

If one make scene lights and setup properly he gets quite realistic scene resembling those LEGO pohtos of their sets from their 80's catalogues... I will show you what I mean later today or tomorrow if you will as now I have not much time...

Also POVRay has much more trouble with right glass feeling (at least with trans dark blue which I am using), whereas BR makes it right with "a flick of a wrist" in contrary + to achieve such realness as BR in POVRay you have to go up with Q settings pretty high which again rising up time needed for such render - all in all BR fits many times better to me than POVRay when it comes to rendering my MOC Space stuff.

I don't see any offence here. You just got it wrong. I used those default (example) settings to show that SunFlow works just the same way POV-Ray does and there are no big differences between these two. What was the greatest advantage of Bluerender? It was its speed. Enhanced settings like multiple light sources and advanced bricks geometry should make rendering time much longer. Plus all that fine tuning process and all of your additional manual work. The initial idea behind Bluerender was "instant render", that's why there are pretty much no settings in it. I'm just saying that LDD2POV-Ray is much better for those heavy, properly set up and detailed renders, while Bluerender is for quick and yet still nice pictures when you think that a simple screenshot is not enough, but don't want to mess with render too much. Most of the images in this topic were made with only default settings.

Adding tons of settings might turn Bluerender into another LDD2POV-Ray with all the same problems in it. How can we ever compare POV-Ray to Bluerender if we're using incomparable settings for both?

EDIT:

Yes the idea of having a secondary library with customized geometries is nice. It would teoretically solve a lot of problems (bevels (given someone can do them), logos, uv mappings where it misses, etc), but it will also open a millions other problems (not last breaking ldd eula).

Anyway, i can still implement obj parsing (since it looks like LDD does it) then you guys can try and use it for whatever you want :)

PS does anybody have some obj files of some bricks to test ?

Why don't you try LGEO, it was made specifically for renders, wan't it? I thought it has just the right "realistic" bricks we need for render.

Edited July 22, 2015 by Garry_rocks

[___]

I don't see any offence here. You just got it wrong. I used those default (example) settings to show that SunFlow works just the same way POV-Ray does and there are no big differences between these two. What was the greatest advantage of Bluerender? It was its speed. Enhanced settings like multiple light sources and advanced bricks geometry should make rendering time much longer. Plus all that fine tuning process and all of your additional manual work. The initial idea behind Bluerender was "instant render", that's why there are pretty much no settings in it. I'm just saying that LDD2POV-Ray is much better for those heavy, properly set up and detailed renders, while Bluerender is for quick and yet still nice pictures when you think that a simple screenshot is not enough, but don't want to mess with render too much. Most of the images in this topic were made with only default settings.

Adding tons of settings might turn Bluerender into another LDD2POV-Ray with all the same problems in it. How can we ever compare POV-Ray to Bluerender if we're using incomparable settings for both?

I do not think there is any chance BR becoming another POVRay with quantum of settings, we are talking only about bits and pieces that pushing BR abilities further to more realism yet not changing its speed in any significat way, so do not worry.

I would put it like this: if now the average rendering time for some average LDD project is, let's say, 3 minutes and the same one with comparable output in POVRay would take several hours then adding some 5+ minutes to BR rendering time means literaly nothing if we get brick seams, logo-on-stud, user defined decor etc. for that, I guess you will agree...and that is the exact path we are trying to go with BR (hope I summarized it enough now )

Why don't you try LGEO, it was made specifically for renders, wan't it? I thought it has just the right "realistic" bricks we need for render.

Yea I suggested this too before as I think this could also be one of the options, but there would be need for finetuning for every single LGEO brick there is + there would be occasions where LGEO parts cannot be used, like flex hoses etc., so I don't know, I would really rather go with the .obj bricks which @msx80 already said he will do that which is super!

Edited July 22, 2015 by bublible

[Victor Imaginator]

...Enhanced settings like multiple light sources and advanced bricks geometry should make rendering time much longer...

Using HDR light doesn't increase rendering time, and can handle incredible complex lighting. Maybe we need to make a few "standart" HDR's that may be integrated within BR? It will improve functionality right out of the box.

[___]

Using HDR light doesn't increase rendering time, and can handle incredible complex lighting. Maybe we need to make a few "standart" HDR's that may be integrated within BR? It will improve functionality right out of the box.

Unfortunately IBL (HDR light) does not work right as it should in SunFlow : it is giving somewhat good results but HDR image is not stretched correctly and it is also oriented in wrong directions and angles for which there are no additional parameters under its settings so in the end you end up with HDR light that is giving strange results (but if one is not too demanding he can get quite interesting results anyway...kind of, let's say, "experimental" lighting )

@msx80

So I did that very simple (empty) UV mapping implementation for .obj files so one can apply modifiers and textures to it via instance object, BUT I did something not quite right cos the image is skewed and shifted to side , maybe you could look into it and possibly just repair what I forgot to see (in case you already do not have your own implementation)?

Edited July 22, 2015 by bublible

[___]

@msx80

Just in case you don't know these two links may help you a lot with implementing/exact understanding of .obj format...and there are really interesting and basically easy to understand stuff there that would enable us doing lots of things with the brick right inside its definition in .obj (like texture, color etc. - you would only have to add synonyms to the color defs in obj that would apply specified material BR and stuff like that, seems not hard to do/implement ), you just need to implement all those options in src which to me seems not that hard when someone like me who knows just a tiny bit about JAVA seem to be able doing it too after a while.

https://en.wikipedia.org/wiki/Wavefront_.obj_file

http://www.martinreddy.net/gfx/3d/OBJ.spec

[Jody Meyer]

I have some Solidworks files I convert to .obj if still needed, just need to know how to attach, unless it's the usual format. Just let me know, also where in the .sc file do you change the light type and location?

[___]

I have some Solidworks files I convert to .obj if still needed, just need to know how to attach, unless it's the usual format. Just let me know, also where in the .sc file do you change the light type and location?

You have to "attach" it using file-mesh object inside your .sc file (search this topic as I post it already here as "how to do it"...and I also did exactly the same for question about the lights, just see some of my previous answers )

Edited July 23, 2015 by bublible

[Umbra-Manis]

Is it possible to add a drop down menu where you can select between multiple .sc files? I'd like to be able to change my scene without manually editing the one scene.sc every time.

[___]

Is it possible to add a drop down menu where you can select between multiple .sc files? I'd like to be able to change my scene without manually editing the one scene.sc every time.

There is absolutely no need for that as we already have the option having separate .sc for every single .lxf so one can have individual versions for each model - just name your .sc according to you .lxf name (like if your model is "rocket.lxf" then your .sc would be also "rocket.sc") and put/copy it in the same folder as your .lxf (leaving the original scene.sc intact, of course, as that will be use everytime there is not individual .sc for respective model!), that's it!

Edited July 23, 2015 by bublible

[Umbra-Manis]

Cool! Thanks!

[___]

Cool! Thanks!

No problem - being glad to help you a bit...

[___]

UPDATE:

@msx80

I just have successfully implemented transform{} block for Point, Directional and Spherical lights (actually had to make new Matrix4 to Point3 method in Matrix4.java which is invoked in case the call comes from Light object during SCParse period...ehm, except IBL and Sunsky, of course) yet leaving all as it was originaly before so one can have either "p" (original option) or newly "transorm{}" (assuming ONLY "translate" and "lddbrick" attributes are used - didn't test what would happen if also "scale" and "rotation" would be in place, beware guys! ) by which we can now easily PLACE ANY LIGHT EXACTLY TO A BRICK POSITION + ADDITIONAL MANUAL FINETUNING enabling us to do things like lights inside cockpit/room or night lamps lighting in the dark at the exact position as our "lamp" brick without long head aching process of trying to figure out the placement of the respective light(s) manually in a "try/error" manner.

EDIT:

Here is a quick sample render showing "transform{}" for several Point light objects in use...(4435 bricks, 1920x1080, rendering: cca. 3 minutes)

Edited July 25, 2015 by bublible

[Lord Tyrus]

Just wanted to say thank you for this fantastic piece of software! After putting up with POV-Ray's hour-long renderings, this is a great breath of fresh air!

[___]

Just wanted to say thank you for this fantastic piece of software! After putting up with POV-Ray's hour-long renderings, this is a great breath of fresh air!

Yea: BlueRender gets still better and better, you know.

[lipanz]

love to see the new update soon

[___]

love to see the new update soon

Well, just in case you expecting implementation of my achievements: I am not sure when and if at all will @msx80 add them into BlueRender, probably not in the upcoming update as I guess he most probably want to test them all personally first which is quite understandable but it will take longer to release it, of course.

Actually I am thinking about something else: if he would agree I can make new topic where I would releasing all of my latest achievement as sunflow.jar file stating for what BlueRender version it is meant to be so anyone who would be interested in such pre-official/unofficial mod can try it out - then you would only need to download my modified sunflow.jar and replace the one in respective BlueRender bin folder.

Edited July 28, 2015 by bublible

[iceleftd]

Well, just in case you expecting implementation of my achievements: I am not sure when and if at all will @msx80 add them into BlueRender, probably not in the upcoming update as I guess he most probably want to test them all personally first which is quite understandable but it will take longer to release it, of course.

Actually I am thinking about something else: if he would agree I can make new topic where I would releasing all of my latest achievement as sunflow.jar file stating for what BlueRender version it is meant to be so anyone who would be interested in such pre-official/unofficial mod can try it out - then you would only need to download my modified sunflow.jar and replace the one in respective BlueRender bin folder.

You could create a section on the wiki for "mods" and publish it there...

[___]

You could create a section on the wiki for "mods" and publish it there...

We'll see what can be done, depends on @msx80 opinion as the original SunFlow mod - the initial one that basically enabled us using .lxf for renders, the one I build all my stuff upon - is his...

On the other hand: he has publicly released his SunFlow mod src code for anyone to mod it further so I guess I could do it straight away without permission but I will rather ask him first anyway.

Except that I think posting it here is more appropriate as almost no one knows about that Wiki page, maybe later.

Edited July 28, 2015 by bublible

[msx80]

Hi there, about obj parsing there are already great java libraries, i started integrating one of them in Bluerender just the other day.

More importantly:

I finally setup the issue tracker! I invite all interested people to join it and move most of the technical discussion there, so we can stop spamming eurobricks and i can keep things organized :)

The url is: https://bitbucket.org/msx80/blueprint/

It's working great, i can manage milestones and everything i need. There are all my previously entered issues, which may not be easy to read for other people, hopefully i'll clean it up with time :)

Thanks!