Stochastic flakes plugin, take 2

[soulburn3d]

Can I get a little more info on "By Render ID"? Does the object always have the same render ID for every render? If you merge the object into a new scene does it have the same renderID?

- Neil

[vlado]

Can I get a little more info on "By Render ID"? Does the object always have the same render ID for every render? If you merge the object into a new scene does it have the same renderID?

No, it is assigned by the renderer based on some internal logic. If you want it to be persistent across merges then I need to do maybe a hash based on the object name and use that, like we do for the VRayMultiSubTex.

Best regards,
Vlado

[soulburn3d]

No, it is assigned by the renderer based on some internal logic. If you want it to be persistent across merges then I need to do maybe a hash based on the object name and use that, like we do for the VRayMultiSubTex.

Isn't there some sort of "Node ID" that every objects gets assigned at creation which is some really huge number (to avoid number clashes with other objects)? Maybe it would be worth adding that?

- Neil

[vlado]

Isn't there some sort of "Node ID" that every objects gets assigned at creation which is some really huge number (to avoid number clashes with other objects)? Maybe it would be worth adding that?

There is a node ID, but it may be changed when a scene is X-Ref'd or when objects are merged.

Best regards,
Vlado

[soulburn3d]

Maybe there's a different way to approach the same problem. Here's the situation...

I have say 3 robot fingers. When I apply the triplanar, I get an identical pattern on each with local space. So I make a node, and assign the triplanar to that node. Now there's a different pattern on each. But then when I rotate the fingers, the pattern will swim because its locked to the node. Now I can make 3 nodes, one for each finger, and have those nodes parented to the fingers, but then I need 3 materials. I click the random offset checkbox and go back to local space, now I have 3 different patterns, but I can't merge the object into a new scene without the pattern changing.

Would it be possible maybe to have a "Frame" attribute in the texture that locks the pattern to a specific frame? That way I could assign a node to the 3 fingers at frame 0 with random offset unchecked, and when I animated the fingers, the pattern would stick since it would always reference back to framem 0 for the node's transform?

- Neil

[vlado]

Well, there are a couple of options:

*) Use the object name for randomization;
*) Use a specified user attribute - I can add a button to generate some random IDs for all nodes that have the texture applied on them;
*) Use the node handle and hope that it is consistent on merge.

Best regards,
Vlado

[super gnu]

cant you just use a different material id on each finger and assign the same material to all of them, with randomise by face id on?

[soulburn3d]

*) Use the object name for randomization;

The issue with that is if you change the object's name the pattern will change.

*) Use a specified user attribute - I can add a button to generate some random IDs for all nodes that have the texture applied on them;

That would be useful to have, although the issue there would be if you add a new object you have to remember to add the attribute to the new object.

*) Use the node handle and hope that it is consistent on merge.

I just tried and the node handles do indeed change on merge. :/

Thanks for looking into it, if we can't specify a frame to lock the randomness, I'll keep thinking, maybe there's another workaround.

cant you just use a different material id on each finger and assign the same material to all of them, with randomise by face id on?

Yes, but that means 1) you lose the ability to use MaterialID for any other function, and 2) You have to remember to set the material ID to a new thing if you add an object to your scene. It'll work in some instances though, it's good to have the option.

- Neil

[soulburn3d]

Oh, one other thing. I'm fine with the "scale" being basically a frequency value, meaning smaller values means bigger pattern (the opposite of "size", where the bigger number is a bigger pattern), but because the spinner only allows for 3 decimal places, there are certain pattern sizes that are unattainable. Can we have an extra decimal place or two? Or maybe this value should be multiplied by 100 so we have more wiggle room?

- Neil

[super gnu]

agreed the scale should be x100. the low numbers are not very user friendly.

[vanished]

cant you just use a different material id on each finger and assign the same material to all of them, with randomise by face id on?

Using the material-IDs for this purpose would prevent the user from using multi-sub materials in a regular way.

Having a user specified handle like a "map-ID" would maybe be a more logical approach? You would indeed have to remember to add the "map-ID" on new objects but that's already the case with material-ID's as well.
Maybe with a (scripted) custom attribute holder that mimics the material-modifier that can be automatically added by the triplanar plugin as well as by a simple script.

This option could than also be added to the list of options in the vrayMultiSubTex.

Cheers,
Tim

[soulburn3d]

I've always wanted vrayMultiSubTex to be able to key off of any User Defined Property, maybe add that to triplanar and vrayMultiSubTex. I already have a script (idSetter in the soulburnScripts) that can assign a random value to any User Definable property.

- Neil

[themaxxer]

I have some issue with big object and the vraytriplanarmap. the rendertimes are a lot higher than with a common box mapping. the lightcache calculations are taking a lot longer. is this a known issue?

best regards
themaxxer

[vlado]

I have some issue with big object and the vraytriplanarmap. the rendertimes are a lot higher than with a common box mapping. the lightcache calculations are taking a lot longer. is this a known issue?

Nope. Do you have a scene?

Best regards,
Vlado

[soulburn3d]

I have some issue with big object and the vraytriplanarmap. the rendertimes are a lot higher than with a common box mapping. the lightcache calculations are taking a lot longer. is this a known issue?

Well, my blended box map script rendered slower than a standard box map, since it was doing more work. So I'd expect the rendertimes to be longer. While not as fast as simple box mapping, I was happy to see the vraytriplanarmap render faster than my blended box map script in the tests I did.

- Neil