WIPs: CTZn

[Pibuz]

Your IMG pic should be renamed in OMG...

[CTZn]

you can make it yourself at home pibuz, high scattering with strong absorbtion and seven years of rendering in a post-industrial environment

Yeah I was glad I figured how to remove the fans in order to clean that mess, it was an easy though quite toxic operation.

[CTZn]

New environmental lighting scheme for your scenes !

(render in progress)

[Oscar J]

Holy crap, render time?

[CTZn]

About one hour, +23mn now.
Indigo took 1mn40 to initialize and start rendering.
bidir+MLT.

By setting the minimum temperature limit to 450°K, init time should be substantially faster.

I have not exported the full sequence yet (120 frames), but I'll fine-tune densities here and share the scene.

If one knows that the sequence can be rendered with local means, let me know and I'll provide. Not for commercial purposes though

[CTZn]

Actually I'm thinking of a mini-contest, where users would be prompted to insert the effect into their own scene (even pre-existing ones for the sake of it !).

Let's name it "Nuke Test: Escape from your Scene"

[thesquirell]

Wait, what....just happened there? I want to know the mechanics behind this scene, was it simulated somewhere, how...I am speechless, excellent.

[CTZn]

Yes I owe a little explication: the setup is a Maya fluid example, essentially simulated but comes with a bit of rigging (one smoke emitter moving up I think, annoying effect btw it's obstructing). So mainly Autodesk's genius (Alias rather), with a scripted twist for Indigo.

No overnight render because I broke the script and was tired. I tried weird scripting gymnastics while the culprit was a typo; until then I genuinely believed that absorbtion was a word

PS: I can generate files that My computer can not render as I have "only" 8GB of RAM onboard. Next renders will feature PT and no dang traced diffraction.

[CTZn]

Not as impressive but still illustrative (cropped images). Please note that each of the three components is expressed within the same specular material for one given sphere; there is never more than one sphere by voxel in the global render. I'm sorry about the lighting setup, this is more of a tech demo

I fixed a few bugs, no more rogue dark banding.

[CTZn]

Once again with a quasi-render, equivalent to a supersampling of 4 accounting for the framebuffer, with a little blurring in-between.

Nearly the actual pic resolution, sorry !
About 16h, original 1280x1024@ss2, moving to the next step !

I did two things that greatly improved performances for a better trade-off.

First I introduced clamping for the output temperature; hotter spheres will be forced down to a maximum temperature. This avoids small clumps, if not individual spheres emitting outstandingly bright (hot) spots. Rendering such extreme effects becomes comfortable.

Then I left jittering alone, with for effect a muuuch faster initialisation from Indigo due to no intersecting mediums being reported.

(I'm wondering how much just printing such each event for massive sets can be the time hog here, devs ? If it happens once, it just needs a one line output. If it happens more, knowing the event count is what matters, not to have each single one reported.)

The effect is that each sphere is now stuck at the center of its voxel, instead of having it moved randomly within its former space's radius. This comes at a visual cost, but then it's a matter of balance between voxel size, RAM and the final resolution (OT: spotted three-body problem, add time for a fourth dimension !).

I can think of a number of things to enhance the tool, it has been a long time since I enjoyed myself with scripting...

If I ever render a sequence myself, this is the MAXIMUM resolution !

PS: I may drop the mass destruction theme soon, as I can tell it's not your type of humour.

[OnoSendai]

(I'm wondering how much just printing such each event for massive sets can be the time hog here, devs ? If it happens once, it just needs a one line output. If it happens more, knowing the event count is what matters, not to have each single one reported.)

Looking good!
Printing can be somewhat slow. What exactly is the printed message?

[CTZn]

Exactly:
Warning: Light 'RaySphere' contained in more than one medium, forcing empty/vacuum medium.
About 5 times per sphere estimated can make a huge printing job (exported 2.5 millions spheres yesterday, killed Indigo after hours initializing) !

Thanks !

On a side note, without jittering centers each sphere is still interecting with 6 other spheres (and as many different media), and the message does not appear...

[yonosoy]

Spectacular...
Another fan of "proceduralism", you know.
Maybe the next week I can start to help you with this shots ...
I will have time to render it because I´m actualy starting studies of art and there are lessons all day.
We talk about when the machine arrives, I will sent to you a mail.

[CTZn]

I'm open for collaboration, I'm just talking more than I'm doing I guess. It's all in the head

One trick I figured out that I wanted to share (the pic is almost 11 months old already !):

One version of the displaced terrain shader is forcing a black color to the negative side, and you can tell wich in this animated gif. The bright image has got the same albedo in both directions. This is a quick hack for an ambient lighting control.

edit: bottom line: displaced terrains are best "enclosed", ie applying the terrain shader only to the top face of a flattened cube. Don't forget to use some angle based optimization so to have the cube adding 5 faces only to the figure.

[pixie]

Once again with a quasi-render, equivalent to a supersampling of 4 accounting for the framebuffer, with a little blurring in-between.

Nuke tamed.jpg

I did two things that greatly improved performances for a better trade-off.

First I introduced clamping for the output temperature; hotter spheres will be forced down to a maximum temperature. This avoids small clumps, if not individual spheres emitting outstandingly bright (hot) spots. Rendering such extreme effects becomes comfortable.

Then I left jittering alone, with for effect a muuuch faster initialisation from Indigo due to no intersecting mediums being reported.

(I'm wondering how much just printing such each event for massive sets can be the time hog here, devs ? If it happens once, it just needs a one line output. If it happens more, knowing the event count is what matters, not to have each single one reported.)

The effect is that each sphere is now stuck at the center of its voxel, instead of having it moved randomly within its former space's radius. This comes at a visual cost, but then it's a matter of balance between voxel size, RAM and the final resolution (OT: spotted three-body problem, add time for a fourth dimension !).

I can think of a number of things to enhance the tool, it has been a long time since I enjoyed myself with scripting...

If I ever render a sequence myself, this is the MAXIMUM resolution !

PS: I may drop the mass destruction theme soon, as I can tell it's not your type of humour.

I believe I can nuke... everybody... I believe I can nuke away! Beautiful!!