Mario Marengo
Mario Marengo
About Me
Connect
LOCATION
Not Specified
WEBSITE
Houdini Skills
Availability
Not Specified
Recent Forum Posts
HIVE23 Slides - Phur Sept. 6, 2023, 9:45 a.m.
Hi there,
I mentioned during our talk [www.sidefx.com] that I would make my slides available "later" since there wasn't really enough time to cover all the technical details on the day. Well, it seems we have reached "later", so here they are
All videos have been removed to reduce size, but the important bits are still there.
This is the second part of our talk, describing some of the challenges we faced in creating a (minimal) procedural hair and fur generator (which we named "Phur"). It was specifically developed as a plugin for Arnold but the analysis is generic and can be applied to any target.
Hope it's useful.
Cheers!
I mentioned during our talk [www.sidefx.com] that I would make my slides available "later" since there wasn't really enough time to cover all the technical details on the day. Well, it seems we have reached "later", so here they are
All videos have been removed to reduce size, but the important bits are still there.
This is the second part of our talk, describing some of the challenges we faced in creating a (minimal) procedural hair and fur generator (which we named "Phur"). It was specifically developed as a plugin for Arnold but the analysis is generic and can be applied to any target.
Hope it's useful.
Cheers!
[GLSL] Multiple Texture Buffers July 18, 2023, 7:57 p.m.
I'm trying to see if I can get an array of textures into my glsl fragment shader, but I'm only partially able to do this, so I'm thinking there must be a better way to do it than what I'm trying right now.
Context:
Current Approach:
Problem:
It appears, from testing, that H19.0 has a limit of ~15 such buffers available/generated for the fragment shader, and H19.5 only gets around 10 max.
Is there an alternate/better way to do this so that I don't hit these texture buffer limits?
If the above approach is correct, is there maybe a way to increase these limits? (didn't see an obvious envar via hconfig)
Or maybe I'm going about it the wrong way?
Thanks in advance for any/all help!
Context:
- H19.5
- GLSL-330
Current Approach:
- My Houdini-side shader node (VOP) has a multiparm of image-path string parms, equiv to an array of images. This gets filled programatically and so can shrink and grow dynamically. Let's say each image-path entry in the array is named image#.
- The image index that should be used for a given prim is stashed as an int prim attribute that gets picked up by the glsl-geo shader and passed to the glsl-frag shader. All of this works as expected.
- The glsl-frag shader declares a set (finite, but large, say 50 or so) of uniform texture buffers named in the same way as the houdini-shader multiparm entries: uniform sampler2D image0; uniform sampler2D image1; etc.. These appear to be generated (loaded/assigned) correctly by the gl engine, and it all works fine... but only up to some limit...
Problem:
It appears, from testing, that H19.0 has a limit of ~15 such buffers available/generated for the fragment shader, and H19.5 only gets around 10 max.
Is there an alternate/better way to do this so that I don't hit these texture buffer limits?
If the above approach is correct, is there maybe a way to increase these limits? (didn't see an obvious envar via hconfig)
Or maybe I'm going about it the wrong way?
Thanks in advance for any/all help!
[HDK] CVEX Woes With HtoA Sept. 11, 2022, 1:36 p.m.
-- SOLVED --
There was a "placement new" operation in the code which used an Arnold allocator. This interfered with Houdini's own allocation strategy and is explicitly warned against in the HDK docs:
Serves me right for being lazy and copy-pasting someone else's code!
There was a "placement new" operation in the code which used an Arnold allocator. This interfered with Houdini's own allocation strategy and is explicitly warned against in the HDK docs:
TFM
Custom Allocators
Houdini is built with special custom allocator libraries that override the default allocation routines (eg. malloc, free, etc.). As such any code you build or link into HDK plugins cannot use their own such libraries such as tbbmalloc_proxy. If you do, then conflicts and crashes can occur as a result.
Serves me right for being lazy and copy-pasting someone else's code!