LuxRender v1.4RC3 release

News & Announcements regarding releases, features, exporters and project coordination.

Moderators: Dade, coordinators

Re: LuxRender v1.4RC3 release

Postby B.Y.O.B. » Mon Feb 09, 2015 8:18 am

acasta69 wrote:With Luxcore API 2.x loop subdivision on the sphere did not take place: is this not supported by LuxCore yet, or should I just update LuxBlend?

It is not supported by LuxCore.
acasta69 wrote:Also the liquid color in the glass on the right side is wrong... What could cause this?

Could you upload the Blender scene?
User avatar
B.Y.O.B.
Developer
 
Posts: 5180
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

Re: LuxRender v1.4RC3 release

Postby acasta69 » Mon Feb 09, 2015 8:24 am

With Luxcore API 2.x loop subdivision on the sphere did not take place: is this not supported by LuxCore yet, or should I just update LuxBlend?

It is not supported by LuxCore.

Ok, but then why is it present in picture number 2? Isn't the rendering engine the same?
Sorry, my understanding of the various Luxrender parts is quite incomplete... :oops:
Are there any plans to support it in future?

I've attached the Blender scene.
Thanks!

waterglass01.zip
(120.42 KiB) Downloaded 139 times
Windows 10 64 bits, i7-4770 3.4 GHz, RAM 16 GB, GTX 970 4GB v382.05
acasta69
 
Posts: 299
Joined: Fri Dec 20, 2013 3:18 am

Re: LuxRender v1.4RC3 release

Postby B.Y.O.B. » Mon Feb 09, 2015 9:53 am

acasta69 wrote:Ok, but then why is it present in picture number 2? Isn't the rendering engine the same?

Good question, I don't know the exact answer either, but I guess it is because the LuxCoreRenderer engine is part of LuxRender. Maybe LuxRender preprocesses the geometry as specified in the LXS file and then passes it on to LuxCore after converting LXS to LuxCore syntax.

API 2.x render looks like this here when I render (Bidir+Metropolis, 500spp):

untitled.jpg

So it seems to be consistent with your API 1.x LuxCore output, apart from the displacement and different tonemapping/gamma.
User avatar
B.Y.O.B.
Developer
 
Posts: 5180
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

Re: LuxRender v1.4RC3 release

Postby B.Y.O.B. » Mon Feb 09, 2015 10:10 am

Btw. it's a bad idea to use a ground plane that large, here is the same rendering with a more reasonable plane size (500spp, settings like above):
Attachments
waterglass01_BYOB.zip
(131.35 KiB) Downloaded 137 times
untitled2.jpg
User avatar
B.Y.O.B.
Developer
 
Posts: 5180
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

Re: LuxRender v1.4RC3 release

Postby acasta69 » Mon Feb 09, 2015 10:30 am

Thanks for checking, B.Y.O.B.
I assume you checked with 1.4RC3, correct? Any thought about what could be wrong in my setup? Maybe I should just wait the 1.4 windows package... :)

Also, any thoughts about differences between pictures 1 and 2? It seems that many things are computed differently in those two cases, the part of image seen through the glass is totally different...

Maybe LuxRender preprocesses the geometry as specified in the LXS file and then passes it on to LuxCore after converting LXS to LuxCore syntax.

What I understand from your answer is this:
    * Luxrender "proper" (how should it be called?) has its own rendering engine, different from LuxCoreRenderer
    * LuxCoreRenderer is eventually called in all LuxCore modes, regardless of which API is used
    * If API 1.x + LuxCore is used, a preprocessing happens before translation and rendering stage, while with API 2.x this is not necessary because export has been done directly in LuxCore syntax.
Is that correct, or am I misunderstanding everything?... :oops:

Thanks for your patience :)
Windows 10 64 bits, i7-4770 3.4 GHz, RAM 16 GB, GTX 970 4GB v382.05
acasta69
 
Posts: 299
Joined: Fri Dec 20, 2013 3:18 am

Re: LuxRender v1.4RC3 release

Postby acasta69 » Mon Feb 09, 2015 10:37 am

B.Y.O.B. wrote:Btw. it's a bad idea to use a ground plane that large, here is the same rendering with a more reasonable plane size (500spp, settings like above)

Thanks for this hint! The second render looks a lot better...
Actually I don't really get why the plane size makes this much difference, but good to know!
Windows 10 64 bits, i7-4770 3.4 GHz, RAM 16 GB, GTX 970 4GB v382.05
acasta69
 
Posts: 299
Joined: Fri Dec 20, 2013 3:18 am

Re: LuxRender v1.4RC3 release

Postby B.Y.O.B. » Mon Feb 09, 2015 10:50 am

acasta69 wrote:Actually I don't really get why the plane size makes this much difference, but good to know!

It is most likely because of a too large epsilon value. This value is determined by the bounding box of all geometry. If the epsilon is too large (or too small), you get precision problems, light leaks etc.
Basically don't have a too large size difference between largest and smallest detail. So to speak, don't model the earth and then place an ant on it and render the ant's eye ;)
I don't want to go into too much technical detail and couldn't find any good explanations by googling "raytracing epsilon" either, so I leave that too you if you want to know more.

acasta69 wrote:I assume you checked with 1.4RC3, correct?

No, I'm using the latest stuff from for_1.5 branch (1.5dev if you will).
acasta69 wrote:Also, any thoughts about differences between pictures 1 and 2? It seems that many things are computed differently in those two cases, the part of image seen through the glass is totally different...

I don't know how exactly LuxCore volume handling differs from LuxRender one. That's a question Dade can answer best I think.
acasta69 wrote:What I understand from your answer is this:
* Luxrender "proper" (how should it be called?) has its own rendering engine, different from LuxCoreRenderer
* LuxCoreRenderer is eventually called in all LuxCore modes, regardless of which API is used
* If API 1.x + LuxCore is used, a preprocessing happens before translation and rendering stage, while with API 2.x this is not necessary because export has been done directly in LuxCore syntax.

Complicated matter.

LuxRender (takes API 1 (LXS) as input) has three "renderers":
  • Sampler (native, "old" engines)
  • SPPM (experimental photon mapper)
  • LuxCoreRenderer (converts API 1 to API 2 and starts the LuxCore engine below)
LuxCore (takes API 2 (SCN, CFG) as input)
  • engines... LuxCore bidir, LuxCore path etc.
User avatar
B.Y.O.B.
Developer
 
Posts: 5180
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

Re: LuxRender v1.4RC3 release

Postby acasta69 » Mon Feb 09, 2015 11:11 am

I've just updated LuxBlend with package luxrender-luxblend25-4ed4f4510828.zip.
Now the liquid in right side glass is rendered with correct colour:

waterglass01_luxcore_bidir_API2x_02.png


There is still some difference in caustics colour for the red liquid, with respect to your render, but maybe now I'll wait for a new version.

Thanks for taking care of explaining all that stuff! :D
Windows 10 64 bits, i7-4770 3.4 GHz, RAM 16 GB, GTX 970 4GB v382.05
acasta69
 
Posts: 299
Joined: Fri Dec 20, 2013 3:18 am

Re: LuxRender v1.4RC3 release

Postby Dade » Mon Feb 09, 2015 11:20 am

B.Y.O.B. wrote:Good question, I don't know the exact answer either, but I guess it is because the LuxCoreRenderer engine is part of LuxRender. Maybe LuxRender preprocesses the geometry as specified in the LXS file and then passes it on to LuxCore after converting LXS to LuxCore syntax.


Yup, loopsubdiv primitives are tessellated into triangles (like hairs) and for this reason it works with LuxCoreRenderer but not with LuxCore API. LuxCore is going to have OpenSubdiv support first or later.
User avatar
Dade
Developer
 
Posts: 8404
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

Re: LuxRender v1.4RC3 release

Postby Dade » Mon Feb 09, 2015 11:27 am

B.Y.O.B. wrote:
acasta69 wrote:Actually I don't really get why the plane size makes this much difference, but good to know!

It is most likely because of a too large epsilon value. This value is determined by the bounding box of all geometry. If the epsilon is too large (or too small), you get precision problems, light leaks etc.
Basically don't have a too large size difference between largest and smallest detail. So to speak, don't model the earth and then place an ant on it and render the ant's eye ;)
I don't want to go into too much technical detail and couldn't find any good explanations by googling "raytracing epsilon" either, so I leave that too you if you want to know more.


There is also another fact to keep in mind when using large planes as background and it is related to infinite light sources (sun, sky, etc.): they are placed slightly outside the bounding sphere of the scene so when you use a very large plane you end to have some very far light source and this increases numerical precision related problems.
User avatar
Dade
Developer
 
Posts: 8404
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

PreviousNext

Return to News & Announcements

Who is online

Users browsing this forum: No registered users and 1 guest