Ah right, I'll take a look into those.
Thanks again, I think this should set me on the right path.
Found 48 posts.
Search results Show results as topic list.
Technical Discussion » Houdini 12.5 geometry light point clouds
- danwood82
- 48 posts
- Offline
Technical Discussion » Houdini 12.5 geometry light point clouds
- danwood82
- 48 posts
- Offline
I'm trying to set up a working example emitting light from an emissive volume, so I can look at the point cloud it generates, and understand what it's generating, so I can roll my own in a correct way.
I didn't spot the shelf tools (I usually have the shelf minimized :-)
Using the Volume Light tool and selecting my volume geometry object, it actually creates a light set up identically to how I'd done it.
Aha… I've just worked out where I was going wrong. However I was setting up the pyro shader must not have been exporting Ce values correctly.
I grabbed the Constant Smoke shader from the Material Palette, and just set the volume object to be a normal scalar volume called “density”, and crucially, specified that shader in the Material field on the geometry light. I'd tried it before with the pyro shader, but it was obviously the shader not the method I had wrong.
I now get meaningful Cd values generated in my point cloud.
Thanks for your help Andrew.
One last thing, can you give any insight into what the weight/volume/A attributes represent, and how they affect the render?
I'm guessing weight has something to do with the importance sampling you mentioned, and volume would be the x*y*z space represented by each point.
With weight and A, I just can't quite work out what the scale of the numbers might relate to - both seem to range between 0.0 and no larger than around ~0.001 per point.
I didn't spot the shelf tools (I usually have the shelf minimized :-)
Using the Volume Light tool and selecting my volume geometry object, it actually creates a light set up identically to how I'd done it.
Aha… I've just worked out where I was going wrong. However I was setting up the pyro shader must not have been exporting Ce values correctly.
I grabbed the Constant Smoke shader from the Material Palette, and just set the volume object to be a normal scalar volume called “density”, and crucially, specified that shader in the Material field on the geometry light. I'd tried it before with the pyro shader, but it was obviously the shader not the method I had wrong.
I now get meaningful Cd values generated in my point cloud.
Thanks for your help Andrew.
One last thing, can you give any insight into what the weight/volume/A attributes represent, and how they affect the render?
I'm guessing weight has something to do with the importance sampling you mentioned, and volume would be the x*y*z space represented by each point.
With weight and A, I just can't quite work out what the scale of the numbers might relate to - both seem to range between 0.0 and no larger than around ~0.001 per point.
Technical Discussion » Houdini 12.5 geometry light point clouds
- danwood82
- 48 posts
- Offline
Thanks Andrew. I'm aware I'm probably going completely off track with it, your help is much appreciated.
I hadn't missed the Cd attribute, just forgot to bring it up. That's actually another point of confusion - I seem to end up with the number 4.82418 baked to the Cd attributes on all particles in the cloud, uniformly, no matter what I do.
What would be the definitive correct way to set up a volume which emitted light?
I'm aware I should be using a Ce export, but I'm not entirely sure how to export it to the point cloud sampler on the geometry light.
The two attempts I've tried are:
1. Create a vector volume in SOPs, call it Ce, and fill it with values. Then point the “Geometry Object” field on the light to that object.
2. Create a scalar volume called temperature, set up a pyro shader which uses temperature as the Fire Color input field, set the volume object material to the pyro shader, and again, point the geometry light to that object.
Both attempts don't seem to inherit anything resembling the data in the Ce or temperature volumes when generating the point cloud, except for only generating points in non-zero areas.
I presume I'm just setting it up completely wrong.
I hadn't missed the Cd attribute, just forgot to bring it up. That's actually another point of confusion - I seem to end up with the number 4.82418 baked to the Cd attributes on all particles in the cloud, uniformly, no matter what I do.
What would be the definitive correct way to set up a volume which emitted light?
I'm aware I should be using a Ce export, but I'm not entirely sure how to export it to the point cloud sampler on the geometry light.
The two attempts I've tried are:
1. Create a vector volume in SOPs, call it Ce, and fill it with values. Then point the “Geometry Object” field on the light to that object.
2. Create a scalar volume called temperature, set up a pyro shader which uses temperature as the Fire Color input field, set the volume object material to the pyro shader, and again, point the geometry light to that object.
Both attempts don't seem to inherit anything resembling the data in the Ce or temperature volumes when generating the point cloud, except for only generating points in non-zero areas.
I presume I'm just setting it up completely wrong.
Technical Discussion » Houdini 12.5 geometry light point clouds
- danwood82
- 48 posts
- Offline
I'm trying to make use of the new point cloud feature for geometry lights in Houdini 12.5, but there's a few too many unexplained quirks and details for me to get my head around. Can anyone explain how it works behind the scenes?
Firstly, it seems that when I specify a geometry node (in this case a fog volume), it will generate a point cloud fine. Then I tell it not to auto-generate, and read the pre-baked pointcloud from disk. This works fine too, but if I then remove the reference to the original geometry, and use the pointcloud exclusively, it will emit light with a darker patch near the object itself. I would assume if point clouds were being used, it would skip normal geometry lighting entirely, but it appears to combine both together.
Secondly, I've been loading the point cloud back in, and looking at the contents. The attributes that appear to contribute are “A” “weight” and “volume”. I'm guessing volume is a representation of the physical size of each point in the cloud. I'm not clear on exactly what effect A and weight have. I can't seem to work out in either case how the numbers correlate with the values in the volume they were generated from. There doesn't appear to be any attribute in the generated point cloud which actually holds information about the volume densities/values it was generated from - not even position, as they're arranged in regular axis-aligned grids, rather than having more points for higher density.
This lead to an interesting test - I was testing out how different volume values altered the values generated in the point cloud - I would presume more light would be emitted from higher values, but it actually appears to emit uniform light from all non-zero points in the volume.
I tested it with a volume which had a constant density of 1.0 in a cylinder around the y-axis. I then made the same cylinder with a linear falloff from 1.0 at the axis, to 0.0 at the edge of the cylinder, and it emitted identical light onto the plane I had placed just below it. If I make the value a constant 0.001 instead, it emits exactly the same again.
Is there a glitch in here?
I'm trying to get to the point where I can generate my own custom point cloud to light with, but I just can't work out how the point attributes relate to the lighting. “A” and “weight” both seem to have similar, but different effects.
Oh, not sure if it matters, but this was all done using “Physically Correct” light attenuation.
Firstly, it seems that when I specify a geometry node (in this case a fog volume), it will generate a point cloud fine. Then I tell it not to auto-generate, and read the pre-baked pointcloud from disk. This works fine too, but if I then remove the reference to the original geometry, and use the pointcloud exclusively, it will emit light with a darker patch near the object itself. I would assume if point clouds were being used, it would skip normal geometry lighting entirely, but it appears to combine both together.
Secondly, I've been loading the point cloud back in, and looking at the contents. The attributes that appear to contribute are “A” “weight” and “volume”. I'm guessing volume is a representation of the physical size of each point in the cloud. I'm not clear on exactly what effect A and weight have. I can't seem to work out in either case how the numbers correlate with the values in the volume they were generated from. There doesn't appear to be any attribute in the generated point cloud which actually holds information about the volume densities/values it was generated from - not even position, as they're arranged in regular axis-aligned grids, rather than having more points for higher density.
This lead to an interesting test - I was testing out how different volume values altered the values generated in the point cloud - I would presume more light would be emitted from higher values, but it actually appears to emit uniform light from all non-zero points in the volume.
I tested it with a volume which had a constant density of 1.0 in a cylinder around the y-axis. I then made the same cylinder with a linear falloff from 1.0 at the axis, to 0.0 at the edge of the cylinder, and it emitted identical light onto the plane I had placed just below it. If I make the value a constant 0.001 instead, it emits exactly the same again.
Is there a glitch in here?
I'm trying to get to the point where I can generate my own custom point cloud to light with, but I just can't work out how the point attributes relate to the lighting. “A” and “weight” both seem to have similar, but different effects.
Oh, not sure if it matters, but this was all done using “Physically Correct” light attenuation.
Technical Discussion » Uniform Volume rendering of particles - render time spikes
- danwood82
- 48 posts
- Offline
(Posted this on odforce too, just trying to cover all bases)
I'm rendering foam for a water sim, with the “Uniform Volume” property applied, and a basic Volume Cloud shader (with the shader density matched to the Volume Density property)
I'm using the Raytracing engine ( - as this doesn't need to generate micro-poly geometry for the Sphere primitives the particles are rendered as, and renders quicker with lower memory usage)
This works fantastically, even with 5million+ particles… except in two or three buckets of the render, where it'll hang on them for 15-30 minutes… the whole rest of the render will rocket through in under 2.
I've switched off every other element of the render, it's definitely the uniform volume particles causing it.
The thing I really don't understand is that it's not linked in any way to the density of particles… it renders the densest areas almost as quickly as the lightest… the couple of buckets that get stuck are in relatively thin areas with only a few (well, only a few hundred) particles.
I've tried tweaking just about everything I can think of:
Stochastic Transparency - doesn't have any effect on Uniform Volumes, as it's not stepping through an actual voxel-volume.
Volume Step Size - same deal, doesn't matter what it's set to, it doesn't affect Uniform Volumes.
Opacity Limit - thought this might have some effect… maybe the rays would give up after a certain density was reached, but no effect at all.
Raytracing Bias - dunno if this applies in any way to uniform volumes, but it didn't have any effect either.
I'm using a VOPSOP that uses point-cloud functions to flag any particles completely-contained-inside any other particles for deletion, which thins out the number of particles by about half, and ensures there isn't too much overlapping particles going on. This actually has an effect, before I was getting about 6 stuck buckets, now it's down to two serious ones.
There's no displacement, no reflection/refraction rays on the volume itself (water surface is reflecting/refracting, but it's not reflecting/refracting the foam, and it does this even without the water surface in the render)
I'm a bit stuck at this point… can anyone familiar with Uniform Volumes suggest anything I haven't thought of?
I'm rendering foam for a water sim, with the “Uniform Volume” property applied, and a basic Volume Cloud shader (with the shader density matched to the Volume Density property)
I'm using the Raytracing engine ( - as this doesn't need to generate micro-poly geometry for the Sphere primitives the particles are rendered as, and renders quicker with lower memory usage)
This works fantastically, even with 5million+ particles… except in two or three buckets of the render, where it'll hang on them for 15-30 minutes… the whole rest of the render will rocket through in under 2.
I've switched off every other element of the render, it's definitely the uniform volume particles causing it.
The thing I really don't understand is that it's not linked in any way to the density of particles… it renders the densest areas almost as quickly as the lightest… the couple of buckets that get stuck are in relatively thin areas with only a few (well, only a few hundred) particles.
I've tried tweaking just about everything I can think of:
Stochastic Transparency - doesn't have any effect on Uniform Volumes, as it's not stepping through an actual voxel-volume.
Volume Step Size - same deal, doesn't matter what it's set to, it doesn't affect Uniform Volumes.
Opacity Limit - thought this might have some effect… maybe the rays would give up after a certain density was reached, but no effect at all.
Raytracing Bias - dunno if this applies in any way to uniform volumes, but it didn't have any effect either.
I'm using a VOPSOP that uses point-cloud functions to flag any particles completely-contained-inside any other particles for deletion, which thins out the number of particles by about half, and ensures there isn't too much overlapping particles going on. This actually has an effect, before I was getting about 6 stuck buckets, now it's down to two serious ones.
There's no displacement, no reflection/refraction rays on the volume itself (water surface is reflecting/refracting, but it's not reflecting/refracting the foam, and it does this even without the water surface in the render)
I'm a bit stuck at this point… can anyone familiar with Uniform Volumes suggest anything I haven't thought of?
Technical Discussion » Render point as particles without explicitly adding particle
- danwood82
- 48 posts
- Offline
I've got this mildly annoying pipeline issue - I have particles exported out from another program as bgeo sequences, with all the correct point attributes set, and I'd like to just use a delayed-load-procedural to bring them straight in at render time.
The only problem is, the bgeos only contain points, they're not particle objects. I know this is as simple as loading them in and using an Add SOP with “Add Particle System”, but I don't want to have to load and recache them just for this.
Ordinarily I would just flick on “Render As Points” on the object, but I want them to render as sphere-primitive particles, not point-primitives.
Any way I can get around this? Is there a way of flagging an object to “Render As Point-Spheres”? Is there some clever point-attribute I could set to override the point-primitive type? Any cunning way to “Add Particle System” at render time?
The only problem is, the bgeos only contain points, they're not particle objects. I know this is as simple as loading them in and using an Add SOP with “Add Particle System”, but I don't want to have to load and recache them just for this.
Ordinarily I would just flick on “Render As Points” on the object, but I want them to render as sphere-primitive particles, not point-primitives.
Any way I can get around this? Is there a way of flagging an object to “Render As Point-Spheres”? Is there some clever point-attribute I could set to override the point-primitive type? Any cunning way to “Add Particle System” at render time?
Technical Discussion » What prevents VOP SOP threading?
- danwood82
- 48 posts
- Offline
Cheers sanostol, that sounds like it's probably the reason, I'm making fairly extensive use of intersect. Ah well, it's just an experiment, back to the drawing board I guess.
Not sure what kellyyy's reply was about. Sidefx forums doesn't really seem like the place for trolling. I'd sooner not give every last detail and attach a bunch of files if I don't need to, as I'm working under NDA. As it happens, someone had a constructive response that pointed me in the right direction.
Not sure what kellyyy's reply was about. Sidefx forums doesn't really seem like the place for trolling. I'd sooner not give every last detail and attach a bunch of files if I don't need to, as I'm working under NDA. As it happens, someone had a constructive response that pointed me in the right direction.
Technical Discussion » What prevents VOP SOP threading?
- danwood82
- 48 posts
- Offline
I've got some fairly heavy stuff (intersections and point cloud functions) running inside a couple of VOP SOP nodes, which would be blissfully fast, except even when I pick a “Number of Threads” option, it'll still run the whole thing on a single thread.
Are there any limitations to VOP SOP threading? ie, will it only work if I don't call any expressions inside, or don't access geometry from other nodes besides the first input, etc?
I'll package it up and attach it if anyone thinks they might be able to shed some light, just thought I'd throw this up first in case anyone has a quick answer…
Are there any limitations to VOP SOP threading? ie, will it only work if I don't call any expressions inside, or don't access geometry from other nodes besides the first input, etc?
I'll package it up and attach it if anyone thinks they might be able to shed some light, just thought I'd throw this up first in case anyone has a quick answer…
-
- Quick Links