save radiosity solution

[christianS]

Hey strat

1. & 2. The Radiosity won't crash or something like that. You can change what you want. But it might be, that the old solution just looks wrong. Let's say you scale a object with a factor of 0.5 the shadow it created in the old solution might be wrong for this scaled version. If you just move a point the old solution might stiil be ok. The same with materielas. If you change a mirror material to a diffuse material and this material is used on many objects, the lighting might change completly.

3. I didn't use it yet, but the algorithm "camera animation" should help here

4. Again, it depends, if you think that the old solution still fits. If you want to use a new light just to add a bit of direct light - than do it! I made a quick test: A plane, a sphere, a point light. Radiosity on, render it. delete the light, deactivate automatic lighting and render again - the radiosity is still there, although there is no Light source. You can even translate the sphere, the radiosity on the sphere will still be there (looks cool)

5. Yep, this should work. The solution is view-independend, those samples are saved in 3D-coordinates. The second step of the computation is view-dependend, but it is rendered every time. Just the view-independend part is saved

Hope this helped a bit
chris

[STRAT]

so in essence it's radiosity baking?

[christianS]

not completly

The precomputed solution consits of samples of varying density. This first pass is saved, you can say baked. But it is not like a texture, because a texture is dense, therefore has a value for every point on the surface. The solution is not dense, it only describes the illumination at discrete points. When you render an image, there are still some computations to finish the radiosity image that are not needed for normal raytracing. Basically, the illumination that is given in the solution is interpolated to get the illumination for the shaded surface-point. This part is not baked.
But yeah, you could say, the solution is baked, but not the whole radiosity computation.

[lllab]

hi strat i am also doing quite heavy gi stuff at the moment, actually it should not be too heavy, but for some reasons c4d renders very long.

so i tried to save the solution, use rendertags etc. my roblem is that i cannot see a time advantage to save the solution- it renders the same time- even worse, i put some rendertags in areas that are not so important and lower the accuracy- and it took longer! in a test!

this is the reason i now tend to not use save solution and also dont use rendertags with different accuracy. what i do use are rendertags for objetcs that should not be seen by gi, this seems to work.

when i have time i will analyse tha problem more- dont have the time right now to find the solution...

cheers
stefan

[neonghost]

the biggest advantage of gi caching is for NET rendering. If the .gi data is available to the network, a heterogenous render farm will be able to render the scene without flicker (assuming your original data is flicker free).

This is pretty indispensable for radiosity walkthroughs.

[STRAT]

cheers fellers for the insight.

[Incarnadine]

I only do still images and frequently with radiosity on and save solution. I will have typically 3 to 4 different cammera positions and usually I find it seems to be fairly independant of camera position. It saves me time when I render the extra camera setups. I do find that it is more susceptable to large object movement/signifigant material property changes.

[davouch]

to the 3rd point:

This is a first cam render with prepass 1/1 and "save solution" option checked - so the GI solution was taken from this view. Picture is good, without any artifacts - just like we are used to get normaly with c4d.

http://david.hlouch.cz/images/cgtalk/_02_camera_animation_1st_cam.jpg (http://david.hlouch.cz/images/cgtalk/_02_camera_animation_1st_cam.jpg)

...and the second pic - the point of my post. The radiosity solution made at the first pic is used here, only camera changed to the oposite side. As you can see there are some quite good visible defects especially located in the fields where the first camera (the one computing the GI solution) was not able to see.
http://david.hlouch.cz/images/cgtalk/_02_camera_animation_2nd_cam.jpg

Well my conclusion here would beter be called "question". Is there any really functional way to render from different cams with one saved GI solution with good results? How it seems to me, the only way to get good results is to render always with render prepass which also means to recompute the GI solution with every camera position change... :rolleyes:
Or am I wrong?

[ZoyPakitou]

I would also like to hear from experienced users...

I'm never sure when to use the "texture baking" option....

How to save render time....

Thanks

Zoy

[Incarnadine]

no i don't think you are wrong. However, my alternate camera positions are not usually so extremely different, different zoom amount and a +/- 30 degree azimuth/elevation delta. I don't seem to see this degree of artifacting and the geometry/texturing usually may mask what does occur to a degree as well. I also tend to work with a higher sample rate than absolutely required for the base image so that may also compensate somewhat. Interesting discussion!

[jackb602]

to the 3rd point:

This is a first cam render with prepass 1/1 and "save solution" option checked - so the GI solution was taken from this view. Picture is good, without any artifacts - just like we are used to get normaly with c4d.


Did you try Camera Animation mode for radiosity? If the only thing that's changing is the camera position, that mode should solve your problem.

Jack

[davouch]

>jack602:I am sorry for not writing this in my 1st post but yes, of course, this results I have got after rendering in camera animation mode. I made this pictures to show you that the answer to the 3rd asked question (originaly posted by STRAT) is negative (with "kind of bigger" camera change you have to recompute the radiosity in the scene).

This fact also negate your (christianS's) thesis that c4d GI solution is view independent. It is IMHO not or maybe it is better talk about it like about GI with prepass because there are no completely blind areas for c4d's GI - their are only not prepassed and therefor kind of "hairy" :). Nor when the camera animation mode is enabled.

I've got almost the same experience with the final render st1 in max which is able to show you the GI solution samples in 3D viewport. However when you will re-render the scene without prepass - those blury stuff is here again.

How it seems to me this "faking radiosity method" based renderers are being slaves of their GI sample prepasses because of some algorithms averaging the light values in the GI sample points.
And this "save radiosity solution" option seems to be just for some cases when you are only about to make some not-so-significant changes in the scene. What a pity! :(

[STRAT]

interesting.

i certainly use the single saved gi solution for animations, but i think i'll stick with a fresh gi solution for every new still i do. as i do at the moment :)

[davouch]

STRAT: i certainly use the single saved gi solution for animations

I don't think the save solution tool is good for animation either. The reasons for this thesis are IMHO obvious. Those strange flickering things you will get everytime you will try to focus camera to areas which were not visible when c4d was computing the GI solution. And this is not acceptable to me.

Or where is the misty mistake I am missing out all the time? This is what I really hate across all the versions from the XL 7 where the GI was introduced for the first time in c4d. :(

[STRAT]

STRAT:

I don't think the save solution tool is good for animation either. The reasons for this thesis are IMHO obvious. Those strange flickering things you will get everytime you will try to focus camera to areas which were not visible when c4d was computing the GI solution. And this is not acceptable to me.(

well i agree too, to a point. i try to render gi animations with a gi accuracy of at least 95%. you can quite happily get flicker free animations using the save single solution as this setting, but for anything less than 95% then you'll get unacceptable flicker.

hopefully the next AR will have sorted all these problems out.

[davouch]

Oh! Such a big number I have never used!! :eek: U're tryin' to say to me that this is possible too :)?
OK

But we have got the same hope:
NEXT AR...:shrug:

Thanks a lot for your experience.

[STRAT]

Oh! Such a big number I have never used!! :eek: U're tryin' to say to me that this is possible too :)?
OK

But we have got the same hope:
NEXT AR...:shrug:

Thanks a lot for your experience.


yeah. rendering at 100% accuracy with a small moderate amount of samples is usually the minimum best if you dont want to use the single saved solution with no flicker, but anything in the high 90's of accuracy with the single saved gi solution is almost as good for a second option. certainly much faster.


obviously, we'd all like to render with decent samples in stoch mode, but hey, i dont think stoch mode has ever heard of the word 'deadline' before :p

allot of peeps like to render with a lower accuracy, say around the 70% mark, and bump up the samples to a high degree. in my experience i find using a much higher degree of accuracy, say around 95% + is more favourable. you need less samples at this percentage and the realism to render speeds are much more user friendly

i usually render all my still work out at 99 or 100% accuracy, and my anims at 95% + if i can afford the time. If i cant, then i'll set up a fakiosity lighting rig and switch off the real GI.

[christianS]

davouch.

This fact also negate your (christianS's) thesis that c4d GI solution is view independent. It is IMHO not or maybe it is better talk about it like about GI with prepass because there are no completely blind areas for c4d's GI - their are only not prepassed and therefor kind of "hairy" . Nor when the camera animation mode is enabled.

Yeah, my mistake. In reply to question 5 i just wanted to say, that the solution works for a different resolution because the GI-points are saved in world-space, not in pixel-space and therefore can be used for different resolutions(the variable prepass-size is a hint for that. But then the manual says, use big prepasses, so i guess, the quality may be worse if you use a prepass, which was computed at low resolution and use it for a high resolution render). But this is of course not necessarily the same like a view independnt solution. The manual even states that Rays from the camera are used for the calculation.

Sometimes it is hard to work with the c4d-gi because nobody actually knows what kind of GI-engine it is. The term radiosity is just used because it is well known, but the actual algorithm is not radiosity, it seems not even to be based on finite elements.
From the manual it seems like they use monte carlo raytracing in the prepass to compute the illumination at those mysterios GI-points, and in the second pass those values are interpolated over the surface or for every shading point it is computed, how much light from every gi-point reaches the shading point (the second version would explain the relativly long rendertimes for the second pass). But i dont understand, how the positionof the gi-points is calculated, maybe from the contrast of the picture that is seen in the prepass (this would also explain, why the quality depends on the size of the prepass)?
Someone here at cgtalk said, the GI-engine is a photonmaper, but i don't belive that. The caustics are obviously generated by a photontracer or even photonmapper. But for the "radisoity" you can not specify the number of photons and a photonmapper would create a view-independend solution.

I would realy like to know how it works....

[christianS]

Oh, one thing: It could still be called view-independend, because the solution can be apllied for another view, therefore the solution is generated and saved in relation to the 3d-space. The solution is not dense everywhere and may not contain the right values for every viewpoint, but those values, that are in the solution, are view-indpendend. I guess it is a question of the definition.

[rolandwoolner]

Hi this is my first post here - but I've had a lot of experience with GI lighting.

What would be really usefull in C4D, for artefact free animation rendering, is if it was possible to render the pre-pass for all of the frames before the final render and then use the accumulated 'cahed' sample map generated with the 'Camera animation' setting for all of the frames in the animation.

It's a technique I've used before with XSI and MentalRay and however low the samples - still gives a solid 'flicker free' sequence. (Rendering out final gathering samples at crappy antialiasing settings and accumulating the FG map - then using the completed map for that camera move.)

Surely this wouldn't be difficult for maxon to implement and would have a zero impact in rendertime - prob saving time as less samples could be used.

I've found the color mapping plugin usefull to help exposure with GI scenes - but wouldn't it be brilliant and simple if the advanced renderer would let us output in 32bit float for correction in shake or PS CS2? (Exr/Tiff?) - Would really help with the post route for arch. rendering.

PS. anyone need a freelance job in london - starting in a couple of weeks time? Arch modelling /animation / rendering? prob. 5-6 weeks work at our studios?

email info(at)split-image.co.uk or phone 020 7490 8682

Roland
Split Image

[moka.studio]

Hi this is my first post here - but I've had a lot of experience with GI lighting.

What would be really usefull in C4D, for artefact free animation rendering, is if it was possible to render the pre-pass for all of the frames before the final render and then use the accumulated 'cahed' sample map generated with the 'Camera animation' setting for all of the frames in the animation.

It's a technique I've used before with XSI and MentalRay and however low the samples - still gives a solid 'flicker free' sequence. (Rendering out final gathering samples at crappy antialiasing settings and accumulating the FG map - then using the completed map for that camera move.)

Surely this wouldn't be difficult for maxon to implement and would have a zero impact in rendertime - prob saving time as less samples could be used.

I've found the color mapping plugin usefull to help exposure with GI scenes - but wouldn't it be brilliant and simple if the advanced renderer would let us output in 32bit float for correction in shake or PS CS2? (Exr/Tiff?) - Would really help with the post route for arch. rendering.

PS. anyone need a freelance job in london - starting in a couple of weeks time? Arch modelling /animation / rendering? prob. 5-6 weeks work at our studios?

email info(at)split-image.co.uk or phone 020 7490 8682

Roland
Split Image

Hi Roland,
just sent you a mail at the address above.
Nice work on the web site btw!
moka-studio.com
jp

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.