Krakatoa

#1921

What is AO in the context of volumetric rendering?

Basically, when rendering a surface, you are asking “Does this surface point see the environment sphere or not?”

But in the case of volumetric rendering, you would have to ask the question about every point in the volume, taking into account all other particles. You cannot do this with Magma because currently you cannot shoot rays against particles, and you cannot check against particles of the same cloud. You could of course use a clone of the point cloud, but there is no good way to look up along a ray to figure out the occlusion.

Something we have done in the past is placing multiple lights on the vertices of a Geosphere around the scene and calculating the lighting using Krakatoa. Krakatoa shadows result in a kind of occlusion test because each particle inside the volume receives less light based on how many particles are between it and the light source. The more lights you use, the better but slower the calculations become.

We are considering some grid-based approach for future versions of Krakatoa to calculate AO and GI, but there is really nothing there to do it right now. It might be doable with Stoke MX 2.0, but I have not tried.

#1922

i got that . maybe the screen space AO is the best solution for now. its fake but good for now
thanks alot Bobo

#1923

You can use the ParticleSumRadius node to get the amount of particles in a radius - the more they are, the more occluded it is. The minor drawback is that you need a second copy of the PRT loader of whatever particle generator you use.

Scene file, max2014:
https://www.dropbox.com/s/aqnebn9of0c6f57/kmx_ao_max2014.rar?dl=0-

Edit: Of course, this is assuming even particle distribution :smiley:

#1924

Sorry for asking in 3dsMax, but there are just random threads about Krakatoa in the Maya forum…

Is it possible to use a Lattice on a PRT loader in Maya? I can´t get it to work… Or is there any workaround…

I have a Realflow mesh whoch I have loaded as a VrayMesh that I needed to tweak and now my particles need the same Lattice…

Cheers and thanks in advance

#1925

Try asking on the official forums! :slight_smile:

http://forums.thinkboxsoftware.com/index.php

#1926

Hi!

Unfortunately, currently it is not possible to use any deformers on PRT objects in Maya.
I love the fact you can use deformers in 3ds Max, but the developers hate me for that (it made the design of the PRT Loader in Krakatoa MX a pain to maintain as it is quite hacky).

That being said, it might be possible to transfer deformations from a deformed mesh (similar to the Krakatoa MX SkinWrap) using a custom Magma setup in Krakatoa MY. The theory is this:

  • Create a PRT Loader to be deformed.
  • Create an undeformed mesh around the particles as reference “initial state” for the deformation.
  • Create a copy of the mesh and apply the Lattice to it.
  • Add a Magma to the PRT Loader and look up the NearestPoint on the first mesh, then do the same with the second mesh and figure out where the particle should go according to the Barycentric Coordinate, Normal and Distance within the given deformed face.

You can even use the RealFlow mesh as the reference and deformer meshes, all you have to make sure is that the topology is always consistent within each frame.

Note that in Krakatoa MX, the Particle SkinWrap supports multiple faces for influence, while the above method is a “rigid” version using only the closest face, so it might not be smooth enough in some cases.

If you are interested, I can send you a simple example where I filled one Cylinder with a PRT Volume, bent a copy of the Cylinder and then transferred the bending to the PRT Volume particles using this method…

#1927

Hi,

I have a scene with multiple PRT containers loading different particle setup, every prt intersects with each other, some are in front and some are occluded.
Each prt has a different render settings and I would export them like separate elements to compositing. Now …In every non-volumetric render(v-ray, arnold, mental-ray, ecc…) there are different solutions like deep compositing or set a matte for occlude objects. Krakatoa makes a good job with matte objects but is only limited to geometry object! I don’t know what are programmers’ difficulties or what issues volumetric render engine involves, but I think that will be some turnarounds that could be used with Krakatoa! I see a lot of small/big vfx house that use Krakatoa like volumetric render engine, with big and tricky projects too and I think that will not be a problem for them!

Anyone has any solution or tips?

Thanks in advance:-)

#1928

It actually is a volmetric renderer :slight_smile: Render a pass with some stuff red, other stuff green, use the channels for comping. Will need to use additive mode, to remove the shadows too.

#1929

I got this tip from Bobo once it worked quite well for my project.

You could add a Magma modifier to each PRT Loader and set a custom channel (e.g. Mapping2) to the color you want. Then in the Render Elements, create a Custom Render Element and connect its output to inputChannel Mapping2. This will give you the color set in the PRT Loader’s Magma written to a render element. There is no other way to determine what object a particle came from, you have to tag them within the PRT Loader itself using Magma…

#1930

Hi there…

In RealFlow there’s a nice script that can take a cached particle sequence and move/snap those particles onto a mesh surface. This can lock foam particles exactly on an ocean’s surface for example…

Now, since i prefer meshing the RF domain’s particles using Frost, is there a way using either Magma or Stoke, to do the same procedure inside Max? That is, create new particles from cached PRT sequences, that have the same properties but moved up or down in Z axis and placed exactly on top of a XMesh-cached Frost mesh sequence?

Thanks in advance…
Greg

#1931

Yes. very easy to do with Magma :slight_smile: Check out the attachment.

#1932

Okay, i’ll give it a shot!
Thanks a lot!

Cheers,
Greg

#1933

Thanks a lot guys, I’ll try soon. :wink:

#1934

What if i want to re-position particles that float above and below the mesh surface, at the same time? What would be the flow for that?
Thanks!

#1935

On the same topic…
Magma doesn’t seem to “see” an XMesh Loader as a “valid geometry node”.
I’m trying to snap particles on an xmesh sequence, but magma doesn’t like that as it seems; see attached pic. Is there any way around this problem?

Thanks!

#1936

I was using this version on max 2012.
I just updated to max 2015 and don’t have access to in-between versions.
I wanted to install it on max 2015 but only versions until max 2013 are supported. I tried to copy manually the dlr file and script, but an error at startup shows that it’s incompatible.
I wonder if there is any possibility to have it work on max 2015? My use of it is limited and I don’t need the latest version, so I just can’t justify a 370 dollars upgrade just to have it work.

I wanted to know from the Krakatoa staff is any option is possible?
Thank you.

#1937

Unfortunately, the 3dsMax 2013 plugin worked only in 2014 since they were based on the same SDK. For 2015, we had to recompile the plugin, and we also added some new features like Repopulation support. KMX v2.3.x with 3dsMax 2015 support uses a new license, and the old 2.1.8 cannot be made to work with this new Max version.

This is the wrong place to ask this question though, I could have missed it here. We have official forum and emails and even a Twitter account for such cases…

Please email me at bobo AT thinkboxsoftware DOT com to discuss this.

#1938

I would like to mention for anyone reading these messages that we solved the problem and it had nothing to do with XMesh. Somehow, the IntersectRay’s first socket was connected to the SECOND socket of the InputGeometry internally (despite what the Editor screenshot shows). I have no idea how it happened, but once the correct connection was recreated from the first output socket of InputGeometry, supposedly it started working. The error message clearly lists that the wrong sockets were connected.

Regarding projecting the particles both below and above the surface, I proposed a simple fix by adding a Vector like 0,0,1000 to the Position->WorldPosition-> branch which would shift the shooting point of the ray 1000 units higher than the actual particle position. This way, any particles up to 1000 units below the surface, as well as any particles above the surface, would be projected down.

The alternatives would involve shooting two rays and checking the validity of their results and using the valid one, or using NearestPoint which would potentially move points to a point that is closer but not exactly “down” along -Z.

#1939

I have prt_loader and prt_volume. prt_loader reflect in prt_volume. How can I export prt_loader and prt_volume in different render elements?

#1940

See this comment you can use the same method add a KCM with mapping to the PRT volume and Loader.

http://forums.cgsociety.org/showpost.php?p=7915917&postcount=1929