KrakatoaSR Softimage Integration Test

[James Vecore]

Here is a video of a plugin I started working on for Softimage. I’m integrating KrakatoaSR as a renderer into Softimage:

 

https://vimeo.com/62377510

 

Please excuse the programmer art. I don’t actually know how to make anything look good with Krakatoa yet.

 

Features So Far:

 

-              Integrated as a renderer plug-in using KrakatoaSR’s C++ API

-              Works with ICE driven point clouds

-              All Krakatoa supported channels are mapped and pulled from ice if they exist (Emission, Absorption, etc)

-              All parameters in KrakatoaSR exposed in the renderer options

-              Region render support

-              Scene lights can be restricted with a group

-              Occlusion mesh support (also through a group)

-              Multi-channel EXR output supported.

 

Now for a real question. While integrating the ICE channel support I noticed that even if I put a Set Data for an attribute like PointNormal, ICE will still optimize it away unless it is being directly used for display or simulation. This seems a tad overly aggressive. My current work around is to drop a log values before the set data and turn off the logging which forces the channel into existence. Please tell there is some other easier way to force a channel to not be optimized away? Or some way from C++ to force the evaluation of the ICEAttribute. I have to imagine other renderers would have similar problems with channels that aren’t needed for viewport display or simulation but are needed for rendering.

 

Thanks,

 

-James

[Eric Thivierge]

On Fri, Mar 22, 2013 at 10:08 AM, James Vecore <jve...@hellopluto.com> wrote:

This seems a tad overly aggressive.

Welcome to our nightmare.

--------------------------------------------
Eric Thivierge
http://www.ethivierge.com

[Rob Chapman]

you can add the attribute as a custom attribute display >Property> attribute display (even switch off viewing of this data in viewport) but this will always keep your attributes intact. pain in the ass , but is the only way currently a gaurantee.

[Cristobal Infante]

Besides all that, your plugin looks great man!!! 

Never used krakatoa myself, but I've seen what it can do. How does it compare to exocortex's fury?

[olivier jeannel]

Christmass in april :)


Le 22/03/2013 15:33, Cristobal Infante a �crit�:

Besides all that, your plugin looks great man!!!�

Never used krakatoa myself, but I've seen what it can do. How does it compare to exocortex's fury?

On 22 March 2013 14:21, Rob Chapman <tekan...@gmail.com> wrote:

you can add the attribute as a custom attribute display >Property> attribute display (even switch off viewing of this data in viewport) but this will always keep your attributes intact. pain in the ass , but is the only way currently a gaurantee.

On 22 March 2013 15:08, James Vecore <jve...@hellopluto.com> wrote:

Here is a video of a plugin I started working on for Softimage. I�m integrating KrakatoaSR as a renderer into Softimage:

�

https://vimeo.com/62377510

�

Please excuse the programmer art. I don�t actually know how to make anything look good with Krakatoa yet.

�

Features So Far:

�

-������������� Integrated as a renderer plug-in using KrakatoaSR�s C++ API

-������������� Works with ICE driven point clouds

-������������� All Krakatoa supported channels are mapped and pulled from ice if they exist (Emission, Absorption, etc)

-������������� All parameters in KrakatoaSR exposed in the renderer options

-������������� Region render support

-������������� Scene lights can be restricted with a group

-������������� Occlusion mesh support (also through a group)

-������������� Multi-channel EXR output supported.

�

Now for a real question. While integrating the ICE channel support I noticed that even if I put a Set Data for an attribute like PointNormal, ICE will still optimize it away unless it is being directly used for display or simulation. This seems a tad overly aggressive. My current work around is to drop a log values before the set data and turn off the logging which forces the channel into existence. Please tell there is some other easier way to force a channel to not be optimized away? Or some way from C++ to force the evaluation of the ICEAttribute. I have to imagine other renderers would have similar problems with channels that aren�t needed for viewport display or simulation but are needed for rendering.

�

Thanks,

�

-James

[Steven Caron]

yes, its aggressive. other renderers have traditional materials applied to surfaces, and if these materials use the attribute shader nodes the ICE data should get pulled. maybe instead of that massive "Shader Options" tab, you could provide actual shaders or a shader compound which you apply to the particle cloud. in that shader compound you would use "Vector Attribute" shader set to point normal, driving the normals port of a "Krakatoa Shader". you can provide these compounds with the default set of ICE attributes to drive the default Krakatoa named channels, this would also allow someone to "repath" a Krakatoa named channel to a differently named ICE attribute. ex. MyCustomVector -> Normal (krakatoa's normal channel).

thanks for your work james, is this to be a plugin for sale through thinkbox? or is it proprietary? or free and open?

[olivier jeannel]

Hi guys,
I'm doing this as an exercise while the machine is rendering...
I'm looking for a way to "naturaly" emit by density,
ie Where particle are small, there are a large number of them, where they are bigger there are less.
Joining a picture to be clear.

I've tried to control emission with Filter by weightmap, and a little bit of Relax Particle it's "ok" solution. but there are still overlapping.
I haven't tried the DartThrow� addon (don't want to install addon while rendering in the background) (plus I think it's more a "random" thrower).
I'm looking for a simple ice logical solution. Idealy something to keep distance between particles based on their size.
Later, I could always throw some Momentum I believe if I want greater contacts...


Maybe some of you have already solved such things?

Olivier

[Jeff McFall]

Maybe some variation of Get Distance to Neighbors or Get Neighboring Particles -  you can then factor that distance into the particle size

 

 

jeff

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of olivier jeannel
Sent: Friday, March 22, 2013 2:45 PM
To: soft...@listproc.autodesk.com
Subject: Dart throw, kind of emit by density ?

 

Hi guys,
I'm doing this as an exercise while the machine is rendering...
I'm looking for a way to "naturaly" emit by density,
ie Where particle are small, there are a large number of them, where they are bigger there are less.
Joining a picture to be clear.

I've tried to control emission with Filter by weightmap, and a little bit of Relax Particle it's "ok" solution. but there are still overlapping.

I haven't tried the DartThrow  addon (don't want to install addon while rendering in the background) (plus I think it's more a "random" thrower).

[olivier jeannel]

Thats clever, I was trying the over way around (getting the distance between particle and delete them if they were too close, but with no good results)
Will try this monday :)
Thank you Jeff !

[Andreas Bystrom]

I did something similar in my scatter compound:
www.wurp.net/files/abScatter.zip

not sure if it still works though, give it a go.

I remember the trouble with simply testing the distance between the particles and then deleting them if they are too close was that it would delete both particles when you only needed to delete one of them, so you need to take that into account if you're going for that approach.

my compound does a kind of simulation with a repeat node that "pushes" the particles away from each other.

--
Andreas Byström
Weta Digital

[olivier jeannel]

Hi Andreas,

Thank you I'll take a look at it. Good to hear I was not alone having difficulties deleting by neighbors :)
I believe your "pushes" compound might be similar to the Relax Particle one wich was cool (working with a repeat node too), kind of "smooth PointPosition (neighbor + array average PointPosition).
But finally I think I'll need something that takes particle size in account (so that they stay close when they are small and "go away" from each other when they are bigger)

but I will look at yours :)

[Raffaele Fragapane]

When dealing with a cloud manipulating itself the same thing to do is to separate sampling and acting on result.
Flag particles with a custom attribute as to delete or not in one pass, and either clone to another cloud with the attribute plugged in the enable port, or purge in the post simulation entry point of the stack with another graph.
A lot easier to tweak and debug too.

[Dan Yargici]

http://cgndev.com/?p=2175

Byungchul has a novel and simple approach that can also take point size into consideration (using it to drive the cutoff distance...)  But there are issues inherent with this approach and cranking up the rate will not necessarily yield a denser distribution.  More often that not, the opposite in fact.  I think Julian explains this on his blog.

I would use Julian's latest Dart Throw addon, personally.  Is there any reason why you won't / can't?

If it's just for a one off generation that you'll freeze off, an alternative would be to emit a bunch of small, non-overlapping points and slowly scale them up using your weightmap to drive the sizes and a simulated tree using the simulate rigid bodies node to ensure they don't intersect.  Then just filter the points using another weightmap or geometry to cut your overall shape.  A bit round the houses, but fairly guaranteed results.

DAN

[olivier jeannel]

Thank you Dan for re-pointing on Julian Johnsn's blog, I didn't see there was a new Dart Throw with weightmap. I think that's exactly what I'm after !
The reason I didn't want to install an addon was that XSI was rendering in background while I was doodeling.
I was not too keen on installing anything while rendering, that's all.

Thank you Raphael, the "law" of separating tree with one tree after the simulation is one to keep in mind. I often do this with simulated trees, but didn't think of it here in that case ^^;

[olivier jeannel]

DartThrow worked superbly !

Magnificent addon if you ask me... :)


Le 24/03/20


13 10:57, olivier jeannel a écrit :

[Dan Yargici]

Great to hear!  Julian is all kinds of genius and very generous with his knowledge if you ever get the chance to work with him.

DAN