I'm finding that, in the VOP context at least, values in Houdini's volumes aren't always what I have set them to be. By this I mean I used a Volume VOP (or a hand-coded .geo file) to store 1.0 density values everywhere in a volume and, in a later Volume VOP, I get density==1.0 failing for some voxels.

The problem seems to crop up consistently on the -X, -Y, -Z sides of the volume bounds, although I've occasionally had it show up in seemingly random spots near the middle of the volume too (couldn't reproduce this for a simple attachment).

Ok, the workaround (round the density to the closest integer value) is easy, so this isn't a show-stopper … but it's really weird and annoying to have to worry about.

Any ideas? I'll admit I didn't spend much time RTFM before coming here


9.5.315

Didn't know about the updated plugin Sean mentioned on the mailing list. I'd give it a shot. I'm going to do the same to see if it fixes some problems I've been having (3dsMax->Maya in my case).

It might be good to get confirmation from SideEffects as to which version of the FBX SDK (2006 or 2009) is being used in Houdini.

I've found Maya's FBX import plugin to be a touch … well … prone to crashing Maya. That plugin (up to Maya 2008 at least) is built using the 2006 SDK.

Even sample apps I write will occasionally crash with the 2006 SDK but are solid with the 2009 SDK.

Of course, this might have absolutely nothing to do with your issue

SreckoM
So to conclude, if I want to use Houdini with Linux 32 bit, not to use Suse 10.3, for now?

To conclude, if you want to use Houdini _period_ (32 bit or 64 bit), skip SUSE10.3.

rjpieke
Ok, thanks guys. Busily downloading the 10.2 DVD. I went from 10.1 to 10.3 when my new motherboard's onboard network connection (Realtek8111b) wasn't detected. Hopefully 10.2 has the appropriate support “built-in”.

Cheers!

Yay … and I'm back

openSUSE10.2 did the trick. There was a mere 1.6GB of patches waiting for me after the DVD installation (one of these days I'm going to have to learn how to get a slimmer installation working - without all the games and crap), but Houdini worked first time.

Thanks again all!

Ok, thanks guys. Busily downloading the 10.2 DVD. I went from 10.1 to 10.3 when my new motherboard's onboard network connection (Realtek8111b) wasn't detected. Hopefully 10.2 has the appropriate support “built-in”.

Cheers!

Ugh … it seems like every time I start a new machine with a new build of openSUSE, there are a whole bunch of new issues.

So here's the scoop …

- downloaded and installed 64-bit openSUSE10.3
- downloaded houdini-9.0.768-linux_x86_64_gcc4.1.7z (which, despite the online installation FAQ does not seem to be an archive but, rather, an executable)
- tried to run the installer … error 1:
bash: ./houdini: Text file busy
- searched Google and found that for whatever crazy reason (if anyone knows why, please let me know!), you can fix this by just copying the file to another directory, so I did that
- tried again to run the installer … error 2:
7-Zip SFX 4.47 beta Copyright © 1999-2007 Igor Pavlov 2007-05-27
p7zip Version 4.47 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)
Processing archive: ./houdini-9.0.768-linux_x86_64_gcc4.1.7z
Error: Can not open file as archive
Archive Errors: 1

And … that's where I'm at.

Any thoughts/ideas?

Is there really any benefit to me running a 64-bit OS on my machine if I've only got 2GB of RAM? Poking around a bit, it seems like getting 64-bit builds of various components (win32_codec, for example) is not as easy as getting 32-bit builds. And, if I switch back to 32-bit openSUSE, which flavour of Houdini should I download then? At first glance, I only saw a 64-bit version for SUSE listed.

Thanks in advance!

circusmonkey
A slight update using the copy SOP stamp with this expression in the X or Y values

varible1 sin(($F*2) + ($PT*2))
varible2 sin(($F*2)*3 + ($PT*5))

I get a nice movement still a bit to uniform , but at least it works ! would it be possible to add some noise into these expressions using noise(x,y,z) certainly interested in thoughts

You could try modifying both the phase and frequency and use rand() instead of noise()

So, for example, something like:

sin( $F*(2+0.5*rand($PT+0.1)) + ($PI*rand($PT+0.2)) )

Cheers!

Simon
x=1 is not the equation of a line, it is a point, or I suppose it could be a plane.

X=1 is a point in 1D, a line in 2D and a plane in 3D.

But, aside from that …

DavidMarcus, you indicated you don't currently like the rotations of your particles. What would you like to be different about them?

Can you post your latest .hip for examination? That would help re suggestions as to how to get the three beams working.

Cheers!

Hi DavidMarcus … the “problem” with the offset is because you're basing your “steering” on velocity and not on position. You're asking the particles to continuously turn to the left (or right) completely independent of where they are. Because their turning rate is constant, they will keep going around in a perfect circle (when viewed along the z-axis) which means that their starting point must be a point ON that circle.

I'm not sure what I'd suggest as the best way to compensate for this other than to shift your source point (which you indicated you don't want to do). You wouldn't have to shift it much though. You could have your source just very slightly away from the origin and then have your helix start very tight and grow bigger quickly until it was the size you wanted.

In terms of modulating the size, I would have been more likely to play with the acceleration relative to position than the velocity relative to velocity, since objects travelling in a perfect circle are always accelerating towards the centre of the circle.

Anyway … maybe (hopefully) this helps a bit

You'll have to copy grids to your particles and render those.

As an aside, watch out if you have lots of transparency in your sprite imagery (ie for volumetric-like stuff - clouds, etc) … RenderMan is not particularly good at rendering many many layers of transparent objects without consuming an enormous amount of memory.

Continuing to digress, if you want to do volumetric rendering, you're MUCH better off writing your own sprite renderer (OpenGL-based, for example). I don't remember the stats Sony quoted re SPLAT on Polar Express, but for our last project here we turned a 30min PRMan render (>1GB of RAM) into a 0.5sec GL render (<25MB of RAM) with comparable image quality.

Have a look at the “Specific” tab in the Renderman ROP … I think there's a field for it there.

Cheers!

One other thing to check is what kind of depth you're storing (i.e., nearest, mid-point, or furthest). The self-shadowing problems typically only show up when using nearest.

Jim Ellis 2001
thanks Rjpieke for the schooling.
Anyone care to comment on question 3?
School me… searve me… leave me out to dry.

Mantra is probably just nice enough to use the geometric normals if none are specified. I bet if you use the Point SOP and create really crazy normals (try replacing ‘$NX’ with ‘rand($PT)’) it'll look different

Cheers!

- Rob

Jim Ellis 2001
Seems like I'm always learning Houdini,
1) Why is the “Space Change” vop used?
2) Why the “Normalize” Vop?

1) This should compensate for a moving camera. Without this VOP, if you tumble your camera around the object, the snow will move.

2) Better safe than sorry, and force of habit

- Rob

I'm posting a screenshot of a simple VOPs network that might get you started. Two things to notice:

The normalized normal needs to be converted from object space to world space before you grab a component.

I'm using the Smooth VOP with a small range to generate the contrast (ie very little falloff between earth and snow)

Hope this helps!

lichtengel
Hi,

I`m still learning Houdini and try to build a Snow-Shader in VOBs.
The snow should lay an flat areas of a mountain and not on steeply faces.

So I need a ramp controlling the coverage, but how!?

One quick way to get started is to take the dot product of the geometry's normal and some global “up” vector (or, if up is along a certain axis - say Y - just take that component of the normal). This “steepness” factor can then be used as the input to drive colour blends, etc.

Cheers!

Mario Marengo
Problem is that the solution you mentioned won't work for non-quad meshes or mixed n-gons – try it on a default poly sphere (triangles) and you'll see what I mean.
Cheers.

Hmm … yeah, that's true. Well, just always stick to quads and life will be great

jeonado
hi, i got the same problem on creating scratch metal surface as well.
i need some anisotropic specular to lit on my geometry.

But this is what i get from the help file:
“Avoid using the Anisotropic Specular model on non-subdivided polygonal geometry because it will look flat shaded.”

I have subdivided my polygonal geometry still get the flat shaded look.
You guys have any ideas to solve this problem?


thanks,
jordan

WARNING: VERY BRIEF AND SOMEWHAT TECHNICAL ANSWER AHEAD

The problem is that most basic anisotropic shaders have something like:

vector anisoAxisX = normalize( Dv( P ) );
vector anisoAxisY = normalize( Du( P ) );

Which is a property of the geometry. In other words, it is consistent across polygon faces, which is why everything looks “flat” or “faceted”. You can get around this, if you have point normals specified, by modifying the shader to instead have:

normal Nn = normalize( N );
vector anisoAxisX = normalize( Dv( P ) );
vector anisoAxisY = anisoAxisX ^ Nn;
anisoAxisX = -anisoAxisY ^ Nn;

This modification exploits the point normals to modify the anisotropic axis calculations to be smoothly varying across the surface, while still being perpendicular to each other.

Anyway, this is just a brief introduction to _a_ possible solution. If you want more details, just let me know.

Cheers!