delayed load with pscale

   12151   7   1
User Avatar
Member
152 posts
Joined: 6月 2008
Offline
Was just working with delayed load a lot recently and wanted to know if there is a solution for tweaking the “pscale” or “width” of the particles AFTER they have been rendered and are being used by the delayed load shader?

example:
sim out 10 sims of small amount of particles with width/pscale set to .2…
create 10 geo nodes that each point to a delayed load shader that points to the individual particle sims.

if i render, and don't like the SIZE of the particles, is there some way to tweak this AFTER the fact? (in reference to using the delayed load)… usually, i sim out particles, and tweak the “pscale” or “width” after they have simmed to get a look that i like. however, since this seems to be “saved” into the files that are being used by the delayed load, can it be set up in some way that this can be changed afterwards?

Thanks a lot,
Jonathan
User Avatar
Member
2624 posts
Joined: 8月 2006
Offline
I think your are confusing what delayed load actually does. You can alter the pscale post sim. Then re render

r
Gone fishing
User Avatar
Member
152 posts
Joined: 6月 2008
Offline
hi there, hmmm. i might be confusing something then.

say i have a geo node named EXPORT_PARTICLES… inside there, i have 10 popnets, with different seeds… Each popnet has it's own chain of nodes afterwards, like “pscale” attr, “velocity multiplier”, “material”… etc, etc… then at the end of each of those chains, i have a null: Particles_01_OUT, Particle_02_OUT… etc etc for all of them.

In ROPS, i have 10 GEO ROPS. Each one points to an individual Null in the popnet chains.
GEO_ROP_1 points to “Particles_01_OUT”
GEO_ROP_2 points to “Particles_02_OUT” etc etc..

I “render” the GEO_ROPS… all 10 of them. as in save the geo to disk.

Then in OBJ level, I have 10 GEO NODES (with nothing inside of them)… Particles_01, Particles_02, etc etc. Each one has a delayed load shader on it. Particles_01 delayed load shader points to GEO_ROP_1's disk file output. Particles_02 delayed load is pointing to GEO_ROP_2's output.

Could you clarify what i'm doing wrong here?

Really appreciate it!

Jonathan
User Avatar
Member
1532 posts
Joined: 7月 2005
Offline
sounds like you have two options at this stage.

You can either recook your simulations and adjust your pscale attribute

OR

you can NOT use the delayed load archive. Simply import your baked sim using a file sop, and modify your PSCALE attribute as needed (using a point sop (particle tab), or using a vopsop.

The ‘delayed load archive’ is meant to be just that… “I've got my asset locked down, just fetch it at rendertime and render it”. By the sounds of it you may have simply rushed the gun on the baking portion of it.

Best,

G
User Avatar
Member
152 posts
Joined: 6月 2008
Offline
hello G,
thanks for your response. luckily, i'm just doing tests right now to learn more about using the delayed load shader, so it's nothing too critical YET. i could just resim and that's fine. it's more just for my own understanding of “if” there are ways to get around these types of issues while using delayed load. Since i had “simmed” out my particles to disk with a particular “pscale”… for use with the delayed load shader but decided hmmm, i kind of want to tweak the “scale” a bit, i figured, hmmm, do i REALLY have to resim this, in order to get the correct “size” for my points, in order to use the delayed load. I'm aware i could just load the sim in with a file sop and use the point sop to tweak the pscale like you suggested however, i was just curious if that was even necessary. if there is some kind of “hack”… similiar to “hacking” rib with renderman, if maybe i could “hack” the “pscale” or possibly other attributes, at render time, WHILE using delayed load shader. Or is it really: you have the final look already, NOTHING else will be changed, so you will use the delayed load shader? just trying to figure out the “full” capabilities and what and what is not possible using it.

So thankful for your response,
Jonathan
User Avatar
Member
606 posts
Joined: 5月 2007
Offline
I've been wondering about the same exact thing.

Looking at the ifd commands, I think an attribute override would fit in there nicely

eetu.
User Avatar
Member
606 posts
Joined: 5月 2007
Offline
Thinking further; having a hierarchical method of setting attributes should be cheaper file/io/memory-wise too, as they would not need to be defined for each point/prim..

eetu.
User Avatar
Member
152 posts
Joined: 6月 2008
Offline
yes exactly
seems like there could be quite a few benefits, flexibility and file sizes….

Let me know if you come up with anything
Jonathan
  • Quick Links