I want the exact opposite. Generate the particles inside a bounding box and just populate the signed distance channel. The Krakatoa Delete can take care of the culling.
- Chad
This was added to the the Bug database as request #306. Let’s see what will happen…
You know, just playing around the last few days I think a strong request for me is to add the same functionality to PRT Volume as the Loader has. Specifically, the dropdown for viewport display type, mostly for the small dot render type - it can be difficult when generating the shell to determine the right shell height because of the large dot. Also, it’d be nice to see the particle count rollout on the PRT Volume.
I assume the optimal workflow is to generate the single frame of the PRT Volume and get that into a PRT Loader as soon as possible, manipulating from there, but without a particle count from the volume, I’m shooting in the dark about how many partitions I need.
Khye
There are a couple of technical problems with this.
First, the PRT Loader is showing known values (when using PRT files) because the count is encoded in the header of each file and is trivial to get, while the PRT Volume cannot predict the number of particles it would generate at render time since it depends on a level set and optional random distribution, shell settings etc. I think we could make it guess the approximate number of particles the render settings would generate, but without actually performing all calculations, we cannot get the exact count.
Second, the PRT Loader is currently implemented as a C++ plugin without any UI and everything you see in the Command Panel is an extended Scripted Plugin. The benefit is that we can add whatever we want to the PRT Loader’s UI with minimum effort. The negative side is that scripted plugins cause all sorts of notification issues due the the half-assed way they have been implemented back in Max 3 days. This is why the PRT Volume/FumeFX/Source and more to come are all pure C++ plugins and changing their UI or adding cool gizmos is a PITA. Chances are the PRT Loader might change to pure C++ plugin someday, but I don’t think the PRT Volume will ever have the UI flexibilities of the PRT Loader.
But we could try at least the first point - attempting to predict an approximate render count…
Since I have been doing some PRT to PFlow stuff lately, I was thinking it sure might be handy to have the option to pipe back into TP. What I am doing is in all other respects dreadfully slow in pf and I am using less than 10k particles, just wondering if TP would be any faster. I am grabbing projection vertex color data, ID’s, and positions from an animated PRT Volume, saving to PRT, piping to PF, and apply the vertex colors. The PRT side is pretty wicked fast an yummy but the pipe back to pf is driving me bananas, it is probably the fact that I have to destroy all particles every frame and recreate them to avoid the out-of-mesh particle ID redraw something-or-other issue.
Any thoughts? pipe dream?
BTW what is Frost?
If we could fix the ID handling so you don’t have to recreate all particles one each frame, PFlow would run quite fast with your setup I think.
The wish for TP File Birth/Update has been around for while, I know Pixomondo wanted that too. Let’s see what will happen in the new release cycle…
Something cool, obviously 
Eek. What a tease !!!
fingers crossed, for the time being I happily deal with the fact that it even works 
it was a long shot that happened to do the job, just not very fast, but all the right things are in all the right places so that is a plus.
sweet, I love cool or cold or sometimes even frozen 
New feature request :: I would like to render particles within camera view Or using volume select modifier over particles and deleting rest of particles (out of from selections) This way i can use more particles and thus saving RAM. Currently I am deleting partcles of PRT volume by deleting geometry out of camera with volume select box attached to camera. Though it is amazingly fast too.
Camera culling isn’t that hard to do in the modifier stack, but if you wanted to do it at render time, by the time you did the sorting and lighitng, the damage in CPU cycles and RAM is already done. I don’t see where the savings would be.
If we were to add it at render time, we would still be doing it at LOADING time (similar to how the culling on PRT Loaders works now). So it would hit the CPU for all shading and transform calculations, but would save RAM before sorting, lighting and drawing is performed. But I have an issue with this as it can potentially affect the lighting - it would have to take into account both camera and all light frustrums. Even if a particle is not visible to a camera, if is visible to a light, it can still affect other particles visible to the camera, and it is getting tricky. I think I would rather leave it to the user’s implementation via volume selections…
That’s what I mean, you have to light the particles before you cull. I didn’t think about the possibility of culling based on an or of camera and light. But yeah, it sounds dangerous.
Wacky wishlist idea… In the SpecificLight render element, would it be possible to have checkboxes for Diffuse and Specular so we could split those apart per light?
More complex, but better workflow-wise… Would it be possible to submit jobs to Deadline per-light? So instead of adding render elements per light, it just submits one job per light? Lights with the same position would be submitted together, of course, so we can keep doing spinny shadows.
- Chad
Don’t see what is wacky about this wish, since we are already able to do Specular and Diffuse passes of all lights, I don’t see why we couldn’t have a checkbox that turns a SpecificLight into Diffuse only or Specular only. But I will leave it to Darcy to decide if it is doable.
This is obviously doable with a customized version of SMTD or a separate submitter. Just pass a post-load script that turns off all lights but the ones that should render (this way the SAME file can be saved and submitted, then modified at render time).
As for the spinny shadows, in an ideal 2.0 world, that should be a feature of a single light.
Btw, there is a hidden experimental option in the current 1.6.0 build - if you type in the Listener
franticparticles.test 4this will cause the shadows to use Sample Range of 4, similar to the way Max Shadow Maps have a Sample Range to blur the shadows. It is not perfect, especially on flat planes turned to particles as it can cause a lot more self-shadowing, but it is another way to play with the quality of the shadows. See if you can make it do anything useful… You can pass any value to this function, IIRC 0 turns it off.
Seems my PRT Batch request post got vaporized when you switched servers, I posted a bug too (well not really a bug but a limit)…
Here goes again a more condensed version than the original:
The ability to have a selectionSet of PRT objects save to their own file sequence.
It in my imagination would use something like partitions, you have a selectionSet list with applicable actions, hit Save and it runs through each selectionSet in the list (either sequentially or by order of importance) and saves a particle sequence for each set.
Why you ask? I have several different characters each filled with its own Volume, saving each to its own sequence is slow and tedious work, it is only about ten or so step each times xNumber of Volumes, this could be/should be an automated process If a bad sequence is found it doesn’t botch your whole setup, you simply resave the bad selectionSet.
Hmmm…
What about a modifier? You could have a modifier with just an index spinner that told that object to be included in a specific PRT file? If you have 3 modifiers, it would be included in those three PRT files, and you could turn the modifiers on and off as needed (which is easier than managing inclusion in selection sets). There would need to be a global control as to what channels were included in each PRT and where those files were saved.
I am privy to any solution
The modifier approach sounds simple and straightforward to use.
I agree selectionSet can be a bear to manage and easy to muff up.
The original plan for 2.0 was to separate the Saving from Rendering.
The saving of particles would be a function exposed to MAXScript, and the whole interface for saving particles would be overhauled to provide any type of batch processing imaginable, including what you described here, saving each event of a PFlow to a different PRT sequence, saving each TP particle group to a different PRT sequence, resaving PRT Loaders to new PRT sequences for the fast creation of proxies with a fraction of the particles, or for culling or reprocessing channels via KCMs and so on.
Right now, the saving of particles is KIND OF scriptable and it would be possible to automate more, but it still requires the setup and triggering of the renderer, so I would like to wait until the saving is a discrete operation that does not require the calling of the renderer before making any changes.
Once this happens, the Save Particles To File Sequence option will probably disappear together with the Save Particles and the Partitioning rollouts and reappear in a dedicated UI similar to the way we moved stuff to the Explorers floater.
But this was the initial idea (has been around for 3 years), the future will show whether it will be implemented exactly that way…
That sounds delicious!
Hi,
Particle formats seem to be converging these days, perhaps a roadmap for inclusion of the various formats might be an idea for a future release?
ie:
Walt Disney open source various formats they use: disneyanimation.com/technology/partio.html
and Naiad is trying to push an open-source particle description framework: exoticmatter.com/overview/
Just a thought
Mike
The funny thing is Disney are talking about unified libraries for dealing with various existing formats, not a new file format for “ruling them all”.
I read the Naiad page and there is no word about an open-source particle description framework I could find. Their data format is closed, and the other format mentioned describes the operator flow. Can you point me to the paragraph where they mention particle formats?
Some thoughts: PRT is an OPEN format (it is documented and everybody is encouraged to read and write it).
But we haven’t made all necessary efforts to make it an open standard because we know of some limitations that we would like to eliminate first with a PRT 2.0 specification. (like metadata to describe coordinate system, units and such). Now it is up to Thinkbox Software to decide what to do though.
Autodesk opted to use the Nucleus cache format for data exchange between Softimage and Maya (with Max eventually adding that too).
They also support a different point cloud format for their LIDAR-data plugin for Max that came from the Autodesk Labs.
In short, Krakatoa will probably add support for all formats worth talking about, and keep on using PRT as its main data storage format since it is somewhat awesome…