PDA

View Full Version : Randomizing Surface HV textures



Chrusion
03-02-2009, 10:16 PM
How do you get surface HVs NOT to have the same identical texture on them? All my gravel HV particles have the same exact shape and bump texture, quite obviously seen when looking at them close up.

Is there any way to randomize the placement of the texture on the HV? World coords (if it were even possible) wouldn't work as I don't want the particles swimming in a sea of texture... just want them all to have different pieces of the texture that sticks to them as they move.

Emitting particles with random rotation and setting HV to use particle orientation is not the same thing and does not randomize the shape of the particles... they still will all be the same.

What say the experts? Is there an obvious check box I'm missing or something? It would be just wrong if HVs all share the exact same location in a texture as though emitted from the exact same point in space, because they are not. They are emitted from various points in space (in this case the verts of a small point cloud).
.

dwburman
03-03-2009, 12:03 AM
I think I tracked down the issue.

The textures that let you select the Noise Type (Perlin Noise, Value Noise, Gradient Noise, etc) seem to lock the texture at the center of the HV and the HVs all look the same. If you use one of the textures that doesn't use those noise algorithms, the HVs all come out unique.

So, don't use Dented, Hetero Terrain or Hybrid Multi-fractal and your rocks won't look like their all from the same mold.

Chrusion
03-03-2009, 10:44 AM
Well, I'm using Denis Pontari's converted RenderMan procedural (not node) texture, Rocks. Does the node version suffer this same "center lock" issue?

You see, the issue is this is the only texture I can find that sculpts surface HV with deep, angular crevasses, just like crushed limestone gravel is... full of sharp, pointy faces. All the other procedurals generate rounded, soft bumps, or angular faces with curved edges at best. Despite even using Rocks, from a distance HVs still have that round marble look. This might be nill if we had an option for CUBIC HVs!!!
.

JMarc
03-03-2009, 10:46 AM
Have you tried turning on World Coordinates on the HyperTexture? That should lock the texture to the "World" center point instead of the particle center.

If the gravel has to move this wouldn't be a good solution as the rocks would swim through the texture but if they are just locked to the ground this should, in theory, work.

Chrusion
03-03-2009, 09:21 PM
World coords... wouldn't work as I don't want the particles swimming in a sea of texture...
Yeah, you didn't read this I guess.

Hmmm... so many moseying by... one of you has to be a pro with an answer when you did HV gravel work for the Big Boys, yes? Com'on... spill it! hehe


And on another note... PRAISE BE TO THE NT WEBSTERS for removing the 5 minute edit limit! <huge sigh of relief>:thumbsup:

On another 'nother note... I finally updated my demo reel and some small parts of my website..

dpont
03-04-2009, 02:46 AM
HV local coordinates of each particle is always the emitter center,
coming from an HV emitter even generated by object surface
or vertices, even set from the group of point of an object,
except if each particle comes from different HV items,
like Nullls with different positions at frame zero (pivot).

I just know a trick, using an Hypertexture node editor
with a particle index, from Particle Info node output,
used as offset in the Position input of the procedural node.

Denis.

Abigor
03-04-2009, 09:04 AM
how can you bring up the node editor for HV texture?!

serge
03-04-2009, 10:50 AM
how can you bring up the node editor for HV texture?!
Denis is talking about his node editor plugin: Node Volume (http://pagesperso-orange.fr/dpont/plugins/nodes/nodes/Node_Editors.html#NodeVolume) (for hypertextures only).

Also, if you install Node Texture (http://pagesperso-orange.fr/dpont/plugins/nodes/nodes/Node_Editors.html#NodeText) you can call a node editor for every tool that has a texture ("T") button next to it. You'll find it under Procedural textures. So, you could also use Node Texture to drive values for hypervoxels.

For Particle Info, as Denis mentioned, you need to install DP-kit (http://pagesperso-orange.fr/dpont/plugins/nodes/Additionnal_Nodes_2.html). "Particle index" is the ID-number of the particle. So, you could use this number to vary the texture position of each particle.

Chrusion
03-04-2009, 11:27 AM
HV local coordinates of each particle is always the emitter center... except if each particle comes from different HV items,
like Nullls with different positions at frame zero (pivot).

I think I understand what you said. So, if an emitter is moving, whether a null or an object... the texture is still locked to where the pivot point was at frame zero, correct?

While experimenting I noticed that switching to World Coords makes the texture 10 times smaller or there abouts. Hmmm... Anyway, after adjusting texture scale down to get the HVs to look the same, if you use a ref obj and move it at the same exact rate as the HVs, then they don't swim in the texture, duh. However, this ONLY works in THIS case where the conveyor gravel moves in only one direction and at a constant speed. Any other motion or turning away from the path will, of course, result in texture swim. So, the conveyor particle issue is sort of kind of solved, but the new particles generated by the bucket scoop follow a dynamic path and so can't use this World Coord Ref Obj 'hack.'

Oh... I changed the texture to CELLS -> F1 Smooth-Step... MUCH better look with sharply chiseled faces (freq = 9, jitter = 1, step size = 1, scale = 100mm on 30mm particles).

Why oh why can't HV do what I want them to do?

Thanks for the info on accessing Nodes for HVs... thought I heard it was possible, but never investigated how. Now we know!
.
.

Chrusion
03-04-2009, 12:24 PM
ALRIGHTY, Then!! "We've got randomness, Houston!"

It took a bit, but I've obtained nearly the same texture on my HVs using DPont's Node Volume and Renderman Collection 3D Cells Texture Node... trick was to invert the Cells texture, which wasn't the case for the Procedural version. Then I tied his Particle Info Node -> ID to the Cells <- Position just as is... which converted the integer? (purple) output to a vector (blue) input. Here I assume the integer number of the particle ID is simply interpreted as meter values and thus "push" the texture to a new position for each particle emitted., ie. for particle ID 1, position = 1, 1, 1. particle 10, position = 10, 10, 10, and so on.

So, now I have nice random, sharp chiseled gravel particles that can go in ANY direction at ANY speed, all locked to a different location in the texture. Woo HOO!

THANKS, guys!

Too bad HVs don't blur using single-pass PRMB... ya have to go the exponentially long render route of multi-pass motion blur and you know we all hate having to render the same frame, that takes 15 minutes, over again 10 times in order to get the classic "stepped" motion blur. Uuugh. I think I'll forgo that and live with any motion strobing that occurs during playback on NTSC monitors (I hate fields, too).

.

Abigor
03-04-2009, 03:39 PM
thanks for the links serge.

i tried this in the T from particle birth rate. i wanted to see if i could set it to use a weight map as the birth rate. i put in the Node Texture from the procedural list, added a weightmap node, plugged it into the scalar end of the Texture Node, but it seemed to have no effect. im not sure why this didnt work. i also tried doing it via a scalar layer set to gradient/weightmap. no go.

then i tried checkerboard and that seemed to work. so the node works, i just dont know why my weightmap wasnt controlling the birthrate as i expected.

Chrusion
03-06-2009, 10:00 AM
Well... I can't use the setup above.

If you thought rendering 30K HVs in 720HD was slow at AA=4 and AD=0.1, try quadrupling the time when you add Particle Info to the mix! YEOWzers! 2 hours/720 HD frame isn't going to cut it one bit. SO, I've abandoned the whole gravel HV thing and am going with a mesh subD to 1,000,000 polys (level 4) and using a Rocks texture dmap instead.

With Interp'd FG (1000 rays, 100 secondary, 3 bounce), render times at the same AA is 7 - 15 min/frm.

Since Surface Effectors was already setup to handle making the transparent gaps in the sub gravel mesh to begin with, I just subdivided that mesh a few more times and hit Tab, deleted the conveyor belt gravel emitter, and I was back to nearly the same effect in no time.

Another reason I can't use the HV Nodes to randomize their texture is that there appears to be a big bad bug (BBB) in Particle Info when used in conjunction with any sort of GI, at least interpolated. As soon as the preprocess hits a voxel, bazoink! 'rendering' ceases (cpu load goes to zero). You can't abort, but Windows doesn't say LW is "not responding" either, so you have to kill LW with Task Mgr. Don't ask how many times I've done that the last couple days trying to figure the problem out... I lost count.

.

Ztreem
03-06-2009, 11:16 AM
Can I ask why you use HV instead of ordinary polys? You can use FX linker to attach the objects to the particles, it usually renders alot faster then HV's.

dpont
03-06-2009, 11:26 AM
...i just dont know why my weightmap wasnt controlling the birthrate as i expected.

Texture node editor is basically a Texture,
with spot local & world position but no point/poly info
to get a vertexmap.

Denis.

dpont
03-06-2009, 11:32 AM
...appears to be a big bad bug (BBB) in Particle Info when used in conjunction with any sort of GI, at least interpolated.

Yes but beside some calculations, the node is
simply asking at the better (possible) time, the Particle Buffer.
Any other context are ignored by both the node editor
and the node.

denis.

Chrusion
03-07-2009, 01:37 PM
why [don't] you use HV instead of ordinary polys? You can use FX linker to attach the objects to the particles, it usually renders alot faster then HV's.

Maybe I've not understood the changes in LW over the last couple versions, but doesn't FX Linker take the object it is applied to and duplicate it, once for each particle emitted, rather than instance it? I mean, 30K objects in layout is NOT instancing and as I understand it, LW doesn't have instancing, so what exactly does Linker DO to place this ONE object on all those particles at once?

The manual is again sorely lacking in all but the description of the plugin's options... not what it does, how to use, etc. At least the index in the "Layout" manual didn't have any other pages other than 282 and 352, which were carbon copies of each other.

Ztreem
03-08-2009, 01:05 PM
Yes, fxlinker just duplicates the object as in copy, no instance. Usually you don't need alot of polys to make gravel so 30K objects at 10 polys is 300K polys not very much these days. It all depends on your needs, but you can always test.

Chrusion
03-09-2009, 04:04 PM
Yes, fxlinker just duplicates the object... so 30K objects
But, Yikes! Won't that break the object selection drop down, drop sideways, drop up, drop explode list? And wouldn't it take like an hour to scroll thru such a list to get to another object "under" it? Scary.

.