PDA

View Full Version : Lightwave radiosity & texture baking



roctavian
09-19-2012, 10:22 AM
My intention was to use cached radiosity with Sensei`s Batch Baking Camera, which can be a great time saver when you have to bake multiple UVs.
Unfortunately, there is a weird bug which makes everything a lot harder.
The problem is caused by a UV bug associated with Global Illumination.
One of the "benefits" of this UV-GI bug, as I don`t like to call it, is that it`s increasing 10-15x times the render/baking time.
Please take a look to the attached scene test. The scene contains a low poly object(4 triangles) and a high poly.
The high poly object is the same low poly object, subdivided a few times and a few bevels here and there.
No UVs on the high poly object and 4 Uvs on the low poly (see image below).


The first UV, named uv_1, is the trouble maker.
The rest of the UVs are copies of the first one, manually modified in Modeler:
uv_2 - modified with the move tool
uv_3 - modified with the move and rotate tool
uv_4 - modified with the move, rotate and scale tool
Also to be noted, the uv_4 rendered area is a couple of time bigger than uv_1.
I also tried to fix the baking errors by killing the polygons and making a new poly using the same vertices. It didn`t fix the problem.
This rendering/baking bug is not related to geometry errors (overlaping polygons, 2pointpolys, distorted polygons, etc.)
The problem occurs only when radiosity is enabled. No radiosity, no problems.

To compare my results with your render times, just load the scene(UV- GI bug.rar) and render each UV, one at a time, by switching the baked UV in the Surface baking Camera properties.
For the results below I used Lightwave 11.0.2 and Lightwave 9.6, where the differences are even more terrible.
The included scene is a LW9.6 scene, which can be used with no changes in LW11.
No matter the type of radiosity is used and the radiosity setting, the problem is still there.
I will not bother you with all the test results I got using this scene, I will post just a few of them:

Lightwave 11.0.2
_____Lightwave SurfaceBakingCamera_____Sensei`s BatchBakingCamera
uv_1......50.9s (GI time= 1.2s)...................49.8s (GI time= 0.1s)
uv_2.......6.3s (GI time= 4.7s)....................1.8s (GI time= 1.4s)
UV_3.......7.4s (GI time= 5.7s)....................2.0s (GI time= 1.6s)
uv_4......12.6s (GI time= 9.6s)....................3.6s (GI time= 3.0s)


Lightwave 9.6
_____Lightwave SurfaceBakingCamera_____Sensei`s BatchBakingCamera
uv_1......84.3s (GI time=45.5s)......................86s (GI time=46.8s)
uv_2 ......5.2s (GI time= 3.7s).....................1.5s (GI time= 1.2s)
UV_3.......6.3s (GI time= 4.6s).....................1.7s (GI time= 1.3s)
uv_4......10.8s (GI time= 7.8s).....................3.1s (GI time= 2.4s)

Even though my intention was to do the tests for this UV-GI bug, I could`n avoid noticing the terrible
Surface baking camera edge padding. The camera was set to 16 pixels border.
Sensei`s Batch Baking Camera is doing a far better job, but it also has some problems. See the attached pictures.
In a production environment scenario these bugs are a nightmare.

I`ll be grateful if some other users will post their test results here, just to be sure I`m not talking rubbish here.

I started this thread here because this is not only a games related technical problem. Today, the classical texture baking technique is used not only in games, but also in architectural visualization, simulations, serious games, offline rendering and virtual cinematography.

I don`t have high hopes this to be fixed in Lw11.5, but still...

Cheers,

erikals
09-19-2012, 10:47 AM
there was a plugin that fixed (walked around) the edge issue by using a post filter in LW.
couldn't find it though, think it was made by a Swedish guy...

(agh, i just can't find it...!)

erikals
09-19-2012, 10:57 AM
not the same, but a photoshop trick >
http://forums.newtek.com/showthread.php?103275-Edge-Bleed-in-baked-maps&p=941488&viewfull=1#post941488

or... >
http://forums.newtek.com/showthread.php?124795-Surface-Baking-Camera-and-texture-borders-error

roctavian
09-19-2012, 11:16 AM
Erikals, thanks for your good intention, but to be honest, I`m fed up by workarounds.
A few more links if someone is willing to try more workaround sollutions:
http://forums.newtek.com/showthread.php?108067-TrueArt-s-Batch-Baking-Camera-v1-0-has-been-released!&p=1030761&viewfull=1#post1030761

Surface Baking Camera and texture borders error (http://forums.newtek.com/showthread.php?124795-Surface-Baking-Camera-and-texture-borders-error)


Wouldn`t be nice to just have this fixed and work normally?

roctavian
09-19-2012, 11:18 AM
And one more thing: none of the aforementioned solutions fix the problem.

And on a side note, I opened this thread for a different bug. :(

Chuck
09-19-2012, 11:27 AM
Please submit a Fogbugz case report for each issue (keep to just one specific bug per case, please; link to instructions is in my sig below, if you need them) and we'll see that this gets on the roster for a look for 11.5.

I have also moved this thread to the proper forum section, LightWave General Support.

erikals
09-19-2012, 11:44 AM
Erikals, thanks for your good intention, but to be honest, I`m fed up by workarounds.
A few more links if someone is willing to try more workaround solutions:

Surface Baking Camera and texture borders error (http://forums.newtek.com/showthread.php?124795-Surface-Baking-Camera-and-texture-borders-error)
there we go, told you he was Swedish ;]


Wouldn't be nice to just have this fixed and work normally?
no workaround? nah, where's the fun in that. http://forums.newtek.com/images/smilies/brians/aiwebs_017.gif

roctavian
09-19-2012, 12:31 PM
Please submit a Fogbugz case report for each issue (keep to just one specific bug per case, please; link to instructions is in my sig below, if you need them) and we'll see that this gets on the roster for a look for 11.5.

I have also moved this thread to the proper forum section, LightWave General Support.

LightWave Bug Report (case 50666) sent.
The bug report I sent is regarding the UV baking associated with GI.

The edge padding bug is also 100% reproducible with the content I sent.
Should I send another bug report?

Thanks for the quick reply.
I know the team is working hard and Lw11 clearly shows that.
I also know there`s many things to be done, but having this fixed for 11.5 would bring peace&joy in my and some others soul.
Again, many thanks, and fingers crossed. :)

Chuck
09-19-2012, 12:54 PM
The edge padding bug is also 100% reproducible with the content I sent.
Should I send another bug report?

Yes, please do. Thanks for the kinds words for the team, I will pass those along, and we will do our best to clear these for the 11.5 release if at all possible.

roctavian
09-19-2012, 03:07 PM
LightWave Bug Report (SurfaceBakingCamera_UV Border error - case 50692) sent.
I`m sure 11.5 will be a strong release.
Many thanks.

Danner
09-19-2012, 06:58 PM
Very odd that the different UVs give such wildly different render times. I did notice that your high poly object has a ton of problems. Geometry intersects itself on the smaller triangles and normals start going all over the place. I removed those and got it to render 3 times quicker.

erikals
09-20-2012, 12:56 AM
probably due this >
"I also tried to fix the baking errors by killing the polygons and making a new poly using the same vertices. It didn't fix the problem."

a user error there.
might wanna file a new fogbugz report with fixed files, as it can be dismissed very fast as a user error, not a bug.

Danner
09-20-2012, 01:57 AM
Erikals, the problem is still there, the real bug is that some UVs take a long time to render, like UV 1 on this scene. The original poster said that the other uvs are the same but just moved around a bit, and those render in a tenth of the time for some reason. I do a ton of baking and often encounter these kinds of UVs that are slow to render, and I mean hours sometimes. I can usually find reasonable render times by moving parameters around in the surface baking camera settings (setting the UV border to 100+ is one thing that seems to help on stubborn cases), but now I see that the UV might be what is causing this and modifying it or re-making it might be a better idea than to fight the baking camera settings.

roctavian
09-22-2012, 05:38 PM
Very odd that the different UVs give such wildly different render times.

Yes, it`s pretty surprising. At least I found the culprit.
Many thanks for testing it.


I did notice that your high poly object has a ton of problems. Geometry intersects itself on the smaller triangles and normals start going all over the place. I removed those and got it to render 3 times quicker.

To be honest, I didn`t care. For the high poly, I cloned the low poly and being made of triangles, I subdivided it a few times. I put those small bevels there just to be sure I look at the high poly bake according to the low poly UV coordinates. The reason I`ve done that is because this way, I had the perfect baking setup: the low poly 3D geometry will be as close as possible to the high poly object, with a small baking distance.
I wasn`t interested how fast is baking each UV. I was interested in the time difference the UVs will bake.

- - - Updated - - -


Erikals, the problem is still there, the real bug is that some UVs take a long time to render, like UV 1 on this scene. The original poster said that the other uvs are the same but just moved around a bit, and those render in a tenth of the time for some reason. I do a ton of baking and often encounter these kinds of UVs that are slow to render, and I mean hours sometimes. I can usually find reasonable render times by moving parameters around in the surface baking camera settings (setting the UV border to 100+ is one thing that seems to help on stubborn cases), but now I see that the UV might be what is causing this and modifying it or re-making it might be a better idea than to fight the baking camera settings.

I encountered in production similar situations where some textures baked in a couple of hours and some others were not finished in 24 hours, sometime even more than 48 hours. And nobody knew why. Pretty hard to deal with, if you ask me. Tweaking the UVs it might help but I`m sure it`s not a guarantee. Sometime you don`t even have the room for that solution, or some other time there are too many to deal with and you don`t have the time or the energy to go back. And I`m sure you want to spend the time with something more creative.

Sensei
09-26-2012, 04:13 PM
_____Lightwave SurfaceBakingCamera_____Sensei`s BatchBakingCamera

Generally Batch Baking Camera is 400% faster than Surface Baking Camera. Except UV_1. Nice.. ;)

Sensei
09-26-2012, 04:28 PM
Turned off GI Interpolation (still GI enabled).. and it's 10 times faster rendering ;)
at least this problematic uv_1

Sensei
09-26-2012, 05:27 PM
Crazy object, crazy settings..

Using not properly connecting by edges object?!

Indirect Bounces 16?!
Secondary Rays 100?!

So, ray is hitting polygon then bounces to improperly made geometry which sends it back, and it's going over and over until Bounces limit is reached. For a lot of spots multiplied by 100..

108131

roctavian
09-27-2012, 03:05 AM
Generally Batch Baking Camera is 400% faster than Surface Baking Camera. Except UV_1. Nice.. ;)

Yes. A great tool that saves a lot of time and effort. Many thanks for building it.

roctavian
09-27-2012, 04:27 AM
Generally Batch Baking Camera is 400% faster than Surface Baking Camera. Except UV_1. Nice.. ;)


Thanks again for pointing that out.:thumbsup:
LightWave Bug Report (SBC - Single threaded baking bug - case 50959) sent.

Even though my intention with this scene was only to point the radiosity interpolation - UV baking bug, this scene has the "merit" of being able to 100% reproduce all three bugs.

roctavian
09-27-2012, 04:34 AM
Turned off GI Interpolation (still GI enabled).. and it's 10 times faster rendering ;)
at least this problematic uv_1

Thanks for finding it. This narrows the field a bit and hopefully makes it easier to get rid of it.

I found this myself too but shame on me for being superficial.
As a matter of fact, I found this bug some time ago but I was too pissed to post it because.... well I don`t wanna say why.


Here`s the LW11.0.2 test results with no interpolation:

Lightwave 11.0.2
_____Lightwave SurfaceBakingCamera_____Sensei`s BatchBakingCamera
uv_1.......9.5s (GI time= 0.2s)....................4.8s (GI time= 0.1s)
uv_2.......9.3s (GI time= 0.4s)....................4.3s (GI time= 0.1s)
UV_3......11.4s (GI time= 0.4s)....................4.2s (GI time= 0.1s)
uv_4......22.9s (GI time= 0.6s)....................8.8s (GI time= 0.2s)

roctavian
09-27-2012, 05:01 AM
Crazy object, crazy settings..

Using not properly connecting by edges object?!

Indirect Bounces 16?!
Secondary Rays 100?!

So, ray is hitting polygon then bounces to improperly made geometry which sends it back, and it's going over and over until Bounces limit is reached. For a lot of spots multiplied by 100..

108131


Hihihi, sooo true, but...... useless. :)

I was hopping not to make it public, but I have to.
The high poly mesh design is the clients choice. I tried so many time to tell him that this is bad, but he didn`t listened to me.
He wanted so much those ugly and crazy bevels.
You have to know, my modeling skills are impeccable.
It`s all my client`s fault.
The same goes for the render settings.
Hope you understand.

Cheers,

Sensei
09-27-2012, 05:54 AM
Thanks for finding it. This narrows the field a bit and hopefully makes it easier to get rid of it.


I don't think LW is buggy in this issue... So nothing to fix..
GI is simply bouncing forever due to broken geometry.
Use GI Bounces 2 instead 16, and it's much faster rendering..
Use GI Secondary samples 10 instead of 100, and it's blazing fast..

Sensei
09-27-2012, 05:57 AM
If you will have flipped reflective sphere and camera inside of it, every single spot will be rendered with maximum Bounce Limit.. rays are bouncing until going to sky, or until reaching bounce limit.

roctavian
09-27-2012, 10:54 AM
Crazy object, crazy settings..

Using not properly connecting by edges object?!

Indirect Bounces 16?!
Secondary Rays 100?!

So, ray is hitting polygon then bounces to improperly made geometry which sends it back, and it's going over and over until Bounces limit is reached. For a lot of spots multiplied by 100..

108131


Hihihi, sooo true, but...... useless. :)

I was hopping not to make it public, but I have to.
The high poly mesh design is the clients choice. I tried so many time to tell him that this is bad, but he didn`t listened to me.
He wanted so much those ugly and crazy bevels.
You have to know, my modeling skills are impeccable.
It`s all my client`s fault.
The same goes for the render settings.
Hope you understand.

Cheers,

Sensei, that was a joke. ;)
I didn`t enjoy your reply, which was a bit abrupt and on top of that nothing to do with the subject.

roctavian
09-27-2012, 10:57 AM
I don't think LW is buggy in this issue... So nothing to fix..
GI is simply bouncing forever due to broken geometry.


Dude, you`re a respected 3rd party developer here.
Why do you jump to conclusions?
It`s hard for me to understand, Don`t you want this to be fixed?

Sensei
09-27-2012, 11:15 AM
Bug can be fixed. If there is no bug, it can't be fixed..

Often programmer after understanding issue, is changing mind, and something what looked like bug, is no longer treated as bug.

LW simply does what you told it to do by placing such, not other geometry..

Of course there is UV Border issue, but that's completely different story.

roctavian
09-27-2012, 11:17 AM
Use GI Bounces 2 instead 16, and it's much faster rendering..
Use GI Secondary samples 10 instead of 100, and it's blazing fast..

Really? :)
Please take a look to the attached scene.
You can find inside 2 more scenes, both of them with 2 indirect bounces, 10 secondary bounce rays.
Both of them have a clean geometry high poly mesh.
One scene has SkyTracer2 as a background, and the other a flpped sphere with the same skytracer but baked as a texture

Lightwave 11.0.2 - Skytracer background, 2 indirect bounces, 10 secondary bounce rays.
_____Lightwave SurfaceBakingCamera_____Sensei`s BatchBakingCamera
uv_1.......26.9s (GI time= 1.9s)....................17.9s (GI time= 0.2s)
uv_2........ 5.1s (GI time= 3.4s).....................1.2s (GI time= 0.8s)
UV_3........ 5.9s (GI time= 3.8s).....................1.2s (GI time= 0.7s)
uv_4.......10.7s (GI time= 6.8s).....................8.8s (GI time= 0.2s)



Lightwave 11.0.2 - baked skytracer texture,2 indirect bounces, 10 secondary bounce rays.
_____Lightwave SurfaceBakingCamera_____Sensei`s BatchBakingCamera
uv_1.......25.6s (GI time= 1.2s)....................16.1s (GI time= 0.1s)
uv_2........ 4.2s (GI time= 2.7s).....................1.9s (GI time= 0.6s)
UV_3........ 4.8s (GI time= 3.9s).....................0.9s (GI time= 0.9s)
uv_4........ 8.6s (GI time= 5.9s).....................1.6s (GI time= 1.1s)

Below you can see the results with the CLEAN GEOMETRY scene + SKYTRACER2, 16 indirect bounces and 100 secondary bounce rays.
What do you think?

Lightwave 11.0.2 - SKYTRACER BACKGROUND
_____Lightwave SurfaceBakingCamera_____Sensei`s BatchBakingCamera
uv_1.......26.1s (GI time= 1.9s)....................18.7s (GI time= 0.2s)
uv_2.........5.4s (GI time= 3.4s).....................1.2s (GI time= 0.8s)
UV_3.........6.0s (GI time= 3.9s).....................1.2s (GI time= 0.8s)
uv_4........10.8s (GI time= 7.0s).....................2.1s (GI time= 1.3s)


The bug is there. In this case UV_1 is rendering 5xtimes slower compared with UV_2 and 3.
If you compare your camera results it`s even more, 9-10x times slower.
This is a very basic and light weight scene. When you have heavy scenes you don`t want to deal with this.

Again.
It`s not about how fast is rendering the texture.
It`s about the time difference for 2 almost identical UVs in the same scene.

roctavian
09-27-2012, 11:20 AM
Bug can be fixed. If there is no bug, it can't be fixed..

Often programmer after understanding issue, is changing mind, and something what looked like bug, is no longer treated as bug.

LW simply does what you told it to do by placing such, not other geometry..

Of course there is UV Border issue, but that's completely different story.

Why do you jump to conclusions?
Test yourself the new scene with a clean geometry and post the results.

Sensei
09-27-2012, 12:09 PM
How you made these uv_2,uv_3,uv_4?

Because when I used Maps > Edit Maps > Copy Vertex Map.. on uv_1 and received uv_5, it's rendering as slow as uv_1
then rotated it a bit, and it's still rendering damn slow in comparison to 2-4 almost 4x slower..

The only noticeable difference between uv_1 and uv_2 is offset, movement down and right..

Hehe.. I moved uv_2 up, and it started rendering 4x slower like uv_1 ;)

roctavian
09-27-2012, 12:35 PM
The UVs are copies of the first UV(Copy Vertex Map), manually modified according to each description:
uv_2 - modified with the move tool (Modify/Translate/Move tool)
uv_3 - modified with the move and rotate tool(Modify/Translate/Move tool+Modify/Rotate/Rotate tool))
uv_4 - modified with the move, rotate and scale tool(the previous 2+Modify/Transform/Size)
I didn`t use the Transform UV Values tool.

Indeed, I moved the polygons in the top left corner of the 0,1 UV area and all the UVs are baking very slow.
Exactly like the UV_1

Great find.:thumbsup: And very weird if you ask me.
Thanks a lot for the testing.
I`ll update the bug report.
Cheers,