Is there a global multiplier for loading particles? I’m testing out DoF and only need to see 1% of my particles, but changing each PRT loader is a chore.
Maxscript you say? Yeah, I suppose. I’ll get back to work now.
- Chad
Is there a global multiplier
for loading particles? I’m
testing out DoF and only need
to see 1% of my particles, but
changing each PRT loader is a
chore.
Maxscript you say? Yeah, I
suppose. I’ll get back to
work now.
This is really tricky because the Render % is animatable, so I wouldn’t dare to touch it via script (there is a way to do this with the VIEWPORT in the Particle Loaders rollout, but not for the rendering because changing the values globally would destroy any animation eventually applied to the Render %.)
What we could do is set the absolute limit of all PRT loaders to a good value. If you know how many particles you have approx. in the scene, say, 100M, and you have 10 loaders, you could set the abs. limit of each loader to 1M and you would get 10M particles, 1M in each loader. I could add this to the Particle Loaders rollout (I think it was there before and I removed it).
A global limit would be better, but we don’t have one right now…
I was thinking a global multiplier that would take all the PRT Loaders’ percentages and limits and multiply by the value in the render panel. So if .1, then a PRT Loader set to load 100% would load 10%. Even if that 100% was animated, you’d take the result and multiply by the global multiplier. Range would be 0-1.
- Chad
I was thinking a global
multiplier that would take all
the PRT Loaders’ percentages
and limits and multiply by the
value in the render panel. So
if .1, then a PRT Loader set
to load 100% would load 10%.
Even if that 100% was
animated, you’d take the
result and multiply by the
global multiplier. Range
would be 0-1.
I know what you want, but I was talking more about what I can give you in the short term (like tomorrow ;o). We are building Release Candidates already, and the only way to put anything remotely similar to global multiplier is at the scripted side, as we are trying not to touch the core anymore.
So I will log the global multiplier as a wish for the future, but give you a mass-limit spinner in the Particle Loaders Rollout in the next build - the total at the bottom of the list shows you how many particles will be rendered, and while not a real percentage, if your PRTs have comparably high counts, it is better than nothing.
You simply select any number of PRT Loaders on the list, enter, say, 5000 into the spinner and press “Set Value” and all Loaders will be set to 5 million limit. You hit the [Render Limit On] button and all Loaders will be limited. You can select other PRT Loaders and set another limit. At the bottom of the list, you will see how many particles they load and how many they would render.
Once you want to render all again, press [Select All], [Render Limit Off] and you are back to normal…
If your particle loaders do not have the render percentage animated, you (or I) could write a script to change all Render Percentage values. Even better, we could apply a global multiplier curve to all Render % tracks and you could change that.
But these are temp. solutions until we are able to change things deep in the Krakatoa core - it is not that simple since it would require Krakatoa to first figure out how many particles WILL be there before even loading them, which will require two passes and make things slower. On top of that, CSV files do not tell us how many particles there are, so we would have to read them twice just to figure that out. And then there are things like PFlows which we would have to pre-evaluate to learn the real count and so on. This would be a rather big change and not just yet another spinner…
Oh, ok, no rush, it’s just a wishlist item for the winter months or something.
- Chad
Oh, ok, no rush, it’s just a
wishlist item for the winter
months or something.
That’s the funny part - we have no way of knowing how urgent users’ wishes are.
It would be cool to post a severity rating with them so we know how to rate them ourselves in the development planning.
Also, we attack them by difficulty, because some of them are rather easy to implement, others might seem easy but are not.
For example, we added leading zeros to PART names (Part001of100.prt) for 1.0 because it was trivial, and also fixed negative frames handling that was misformatted like particles_00-1.prt instead of particles-001.prt
So if you would rate the importance of your requests when you post them, we would have a better way to understand how to approach their implementation.
Thanks in advance!
I’ve assumed that any wish made post beta 18 was considered low priority since you guys were locking down for release. Sorry.
- Chad
That’s all good but we’d need a ladder of priority!
Say 1 to 5
1 being top priority and 5 being something like “would be cool”
Marc-André Carbonneau
Senior VFX artist
Ubisoft Digital Arts
Montréal
514.490.2000 x:3443
Alright, I’ll add polls to future wishlist items. And feel free to comment on any wishes you see.
- Chad
That’s all good but we’d need
a ladder of priority!
Say 1 to 5
1 being top priority and 5
being something like “would be
cool”
That’s a good solution. But we don’t really need to enforce a scale. If somebody comes and says “Hey, this is stopping my production, please do something”, we will assume it is High Priority :o)
Looking at what Chad & Co are producing with Krakatoa, we always feel his wishes are high priority unless told otherwise, so we tend to squeeze in fixes and scripted solutions into the product even a week before release ;o)
(See “Box 3 Disk Cache Renaming Support”, for example)
Yeah, but we’re going to be your worst case customer for the most part. We’re moving from a voxel to point based rendering system, as opposed to just looking for a better way to make puffs of dust. Our wishes are generally about small stuff that, when you have 6 artists working full time on krakatoa, add up to big improvements. I’m sure most customers won’t use these features more than once or twice a year.
We’ve had a few show-stoppers, but most could be worked around. That disk cache thing was great, as was the rendering of vertices that you added in an early beta. And publishing the CSV/PRT format spec has allowed us to get our production renders out REALLY fast. So we’re not at all feeling ignored.
Though I would like variable sized points and high level control of the rasterizing output. We have big plans for that… Hope 1.0 isn’t a long lived product. 
- Chad
… so we tend to
squeeze in fixes and scripted
solutions into the product
even a week before release ;o)
Nothing stopping you from releasing it as Krakatoa 1.7 at Siggraph. That way everyone will see how much you’ve worked on it since Boston. And they’ll assume that the software is well tested, which it is. And beta testers will think they got all those point updates up to 1.7 for free.
EDIT: Just don’t try to retroactively charge us for maintenance/support. We aren’t falling for that.
- Chad
I was thinking a global
multiplier that would take all
the PRT Loaders’ percentages
and limits and multiply by the
value in the render panel. So
if .1, then a PRT Loader set
to load 100% would load 10%.
Even if that 100% was
animated, you’d take the
result and multiply by the
global multiplier. Range
would be 0-1.
In the upcoming v.1.1.0 which we will start Beta-testing next week, we implemented a Truly Global multiplier which takes a percentage of ALL particles that have been scheduled for rendering, not just those loaded from disk. So if you have 1 million particles coming from PFlow, 100K from geometry vertices and 20 million in PRT Loaders, setting the Global Percentage to 1% will load every 100th particle of each of these sources.
It is not the best we could do because it discards particles AFTER they have been read from their source and shaded (but before they have been put into memory and before any sorting/lighting/rendering). In a future update, we might be able to change the internals to perform this during the actual loading and avoid the shading step. Of course, if the particles already come with their own color channel, for example from a PRT Loader, this really isn’t an issue.
The actual lighting and rendering of 1% of the particles is of course 100 times faster.