> NPointGroups 1 NPrimGroups 1
You have some groups declared in the header, but apparently there are none in the geo's body.
Set the numbers to 0: “NPointGroups 0 NPrimGroups 0”.
For some reason GPlay is more forgiving about this and can parse such ill-formatted files.
The new geo format is different indeed, it's JSON-based, to save out an old-style reference file select .hclassic in the format drop-down.
Found 51 posts.
Search results Show results as topic list.
Technical Discussion » GPlay loads geo, but Houdini does not.
- axebeak
- 51 posts
- Offline
Technical Discussion » Unwrap by polygon
- axebeak
- 51 posts
- Offline
Attributes can be added in VOP with Bind Export, but in this case it seems more convenient to use Vertex SOP to assign UVs:
u = vector4(0,0,1,1)
v = vector4(0,1,1,0)
u = vector4(0,0,1,1)
v = vector4(0,1,1,0)
Technical Discussion » Cd attribute in the Geometry COP
- axebeak
- 51 posts
- Offline
You can use Intersect inside VOP COP generator to cast rays manually and then sample attributes at hit positions using PrimAttrib (it'll return interpolated values for point attrs). It's slow though, but sometimes can still be useful.
I'm attaching a simple scene to demonstrates this.
I'm attaching a simple scene to demonstrates this.
Technical Discussion » REC709 Look-up Tables
- axebeak
- 51 posts
- Offline
L is for linear-light, and V is for video-signal (sometimes V', the prime symbol used to denote gamma-corrected, non-linear, values).
Technical Discussion » REC709 Look-up Tables
- axebeak
- 51 posts
- Offline
This is Hscript so you need to run it from Houdini - open the Textport (Windows-> Hscript Textport, or press Alt+Shift+T), then type the following command:
source "full_path_to_hs_file" full_path_to_lut_file
If lut_path is omitted the file will be saved to your home directory.
(And, if the above method fails, I'm attaching the LUT file as requested.)
source "full_path_to_hs_file" full_path_to_lut_file
If lut_path is omitted the file will be saved to your home directory.
(And, if the above method fails, I'm attaching the LUT file as requested.)
Technical Discussion » REC709 Look-up Tables
- axebeak
- 51 posts
- Offline
The inverse transform is this (the linear breakpoint is at 0.018*4.5 = 0.081):
if V < 0.081: L = V/4.5
else: L = ((V + 0.099)/1.099)^(1/0.45)
The following hscript will generate the inverse LUT.
set outname=$arg1
set outname=`ifs(!strlen($outname), “Lin709.lut”, $outname)`
set len = 256
echo “Version 1” > $outname
echo “Format any” >> $outname
echo “Type C” >> $outname
echo “From 0 1” >> $outname
echo “To 0 1” >> $outname
echo “Black 0” >> $outname
echo “White 1” >> $outname
echo “Length ”$len >> $outname
echo “LUT:” >> $outname
echo “RGB {” >> $outname
for i = 0 to `$len-1` step 1
set V = `$i/($len-1)`
set L = `if($V < 0.081, $V/4.5, pow(($V + 0.099)/1.099, 1/0.45))`
echo “ ”$L >> $outname
end
echo “}” >> $outname
if V < 0.081: L = V/4.5
else: L = ((V + 0.099)/1.099)^(1/0.45)
The following hscript will generate the inverse LUT.
set outname=$arg1
set outname=`ifs(!strlen($outname), “Lin709.lut”, $outname)`
set len = 256
echo “Version 1” > $outname
echo “Format any” >> $outname
echo “Type C” >> $outname
echo “From 0 1” >> $outname
echo “To 0 1” >> $outname
echo “Black 0” >> $outname
echo “White 1” >> $outname
echo “Length ”$len >> $outname
echo “LUT:” >> $outname
echo “RGB {” >> $outname
for i = 0 to `$len-1` step 1
set V = `$i/($len-1)`
set L = `if($V < 0.081, $V/4.5, pow(($V + 0.099)/1.099, 1/0.45))`
echo “ ”$L >> $outname
end
echo “}” >> $outname
Technical Discussion » RGB channel swapping
- axebeak
- 51 posts
- Offline
So this means there is actually a bug in ChannelCopy?
I mean, when I'm saying “set C.r to Input2: C.r” what it actually does is “set C.b to Input2: C.b”. I used to just select the first component on the list as R, never actually reading the name, so this went unnoticed for some time.
Is it possible that the source of this bug is the same as swapped channels in CopNode.allPixels()?
I mean, when I'm saying “set C.r to Input2: C.r” what it actually does is “set C.b to Input2: C.b”. I used to just select the first component on the list as R, never actually reading the name, so this went unnoticed for some time.
Is it possible that the source of this bug is the same as swapped channels in CopNode.allPixels()?
Technical Discussion » RGB channel swapping
- axebeak
- 51 posts
- Offline
There appear to be some places in Houdini where Red is Blue and vice versa.
See the scene and screenshots, this was tested under Hou11.0.581/Win64, 11.0.834/Win64, 11.1.118/Win64 and 11.1.206/Win32.
1) using 24-bit TGAs as textures - this only happens in OGL (tested with both NVidia & ATI cards), Mantra renders them properly, COP/File reads them correctly as well;
2) COP ChannelCopy - see pictures 2 and 3, and examples in /img/comp1 … I don't know if this is related somehow to problem #1, ChanCopy actually has the channels in its menu listed in “reversed” order - C.b, C.g, C.r (so is this a bug or just a typo in the interface?);
3) Python - CopNode.allPixels(“C”, “r”) returns the blue pixels, “b” returns the reds - see example Python COP filter in the scene;
#1 seems like a bug clearly, but what about ChannelCopy? I seem to remember that it works this way since Hou9. But CopNode has this quirk as well. So maybe these are related problems.
See the scene and screenshots, this was tested under Hou11.0.581/Win64, 11.0.834/Win64, 11.1.118/Win64 and 11.1.206/Win32.
1) using 24-bit TGAs as textures - this only happens in OGL (tested with both NVidia & ATI cards), Mantra renders them properly, COP/File reads them correctly as well;
2) COP ChannelCopy - see pictures 2 and 3, and examples in /img/comp1 … I don't know if this is related somehow to problem #1, ChanCopy actually has the channels in its menu listed in “reversed” order - C.b, C.g, C.r (so is this a bug or just a typo in the interface?);
3) Python - CopNode.allPixels(“C”, “r”) returns the blue pixels, “b” returns the reds - see example Python COP filter in the scene;
#1 seems like a bug clearly, but what about ChannelCopy? I seem to remember that it works this way since Hou9. But CopNode has this quirk as well. So maybe these are related problems.
Technical Discussion » Houdini precision
- axebeak
- 51 posts
- Offline
Are you sure those numbers were integers?
This happens with floating-point values when the field is in “expression” mode (see the pic). (Edit: Sorry, didn't see this was already explained while I was typing my response.)
I don't think it has anything to do with internal precision though, some numbers are just not representable exactly in binary form, either floats or doubles.
For example, try the following in Python Shell (Python uses doubles):
print ‘%(#).17f’ % {“#”:1.0/10}
print ‘%(#).17f’ % {“#”:0.7}
This happens with floating-point values when the field is in “expression” mode (see the pic). (Edit: Sorry, didn't see this was already explained while I was typing my response.)
I don't think it has anything to do with internal precision though, some numbers are just not representable exactly in binary form, either floats or doubles.
For example, try the following in Python Shell (Python uses doubles):
print ‘%(#).17f’ % {“#”:1.0/10}
print ‘%(#).17f’ % {“#”:0.7}
Edited by - Dec. 5, 2011 14:56:29
Technical Discussion » Walk cycle
- axebeak
- 51 posts
- Offline
With MotionFX looping an animation is really just a couple of clicks.
Here is an example:
http://kinnabari.googlecode.com/svn/wiki/walk_cycle.zip [kinnabari.googlecode.com]
Note that there are some extra Channel and Composite nodes in CHOP, you probably don't need any of those - this is related to my weight capture setup.
Here is an example:
http://kinnabari.googlecode.com/svn/wiki/walk_cycle.zip [kinnabari.googlecode.com]
Note that there are some extra Channel and Composite nodes in CHOP, you probably don't need any of those - this is related to my weight capture setup.
Technical Discussion » system("date /T") on windows not working
- axebeak
- 51 posts
- Offline
I believe on Windows system() uses c-shell, not the native command processor, and this causes problems with built-in commands such as ‘date’. You can try the following expression (it works for me):
`system(“cmd /C date /T”)`
`system(“cmd /C date /T”)`
Technical Discussion » REC709 Look-up Tables
- axebeak
- 51 posts
- Offline
Ah-hah, I swapped the wires in the initial example - re-uploaded correct graphs and the scene, sorry about that!
Nonetheless the text and the formulas are correct.
Assuming you're using 0-1 linear image as your input, simply use its R channel, that will represent the linear light.
Yes, that's correct.
I thought it should be possible to save LUT from an instance of Lookup COP (using VOPCOP filter as the input table), and indeed it allows to open the Save LUT dialog, but throws an exception upon saving. Well, Lookup is placed under PixelOp in the TAB menu, but the node is not blue, so…
Anyway, as a temporary solution I'm attaching a small hscript that simply calculates the table. You can execute it from textport using “source” command. The archive includes pre-generated LUT as well.
Nonetheless the text and the formulas are correct.
the intensity channel as your input value
Assuming you're using 0-1 linear image as your input, simply use its R channel, that will represent the linear light.
the RGB values as your output in the filter.
Yes, that's correct.
Also when I go to save the LUT, is says the I needs to be a pixelOP node (blue node)
I thought it should be possible to save LUT from an instance of Lookup COP (using VOPCOP filter as the input table), and indeed it allows to open the Save LUT dialog, but throws an exception upon saving. Well, Lookup is placed under PixelOp in the TAB menu, but the node is not blue, so…
Anyway, as a temporary solution I'm attaching a small hscript that simply calculates the table. You can execute it from textport using “source” command. The archive includes pre-generated LUT as well.
Technical Discussion » REC709 Look-up Tables
- axebeak
- 51 posts
- Offline
Rec709 encoding is this:
V = 1.099*(L^0.45) - 0.099
In addition there is a linear segment for very low values of linear light:
if L < 0.018: V = 4.5L
So Rec709 exponent is 0.45 but because of the scaling and offset in the formula above it is closer to 0.5, that is square root function.
I'm attaching a scene where all these functions are plotted via VOP SOPs (you can do the same via VOPCOP filter and then save the LUT).
For the same reason (scaling and bias in the encoding formula), actual sRGB exponent is closer to 0.45 than to 0.42 (1/2.4).
Actual sRGB formulas:
V = 1.055*(L^0.42) - 0.055
if L < 0.0031308: V = 12.92L
V = 1.099*(L^0.45) - 0.099
In addition there is a linear segment for very low values of linear light:
if L < 0.018: V = 4.5L
So Rec709 exponent is 0.45 but because of the scaling and offset in the formula above it is closer to 0.5, that is square root function.
I'm attaching a scene where all these functions are plotted via VOP SOPs (you can do the same via VOPCOP filter and then save the LUT).
For the same reason (scaling and bias in the encoding formula), actual sRGB exponent is closer to 0.45 than to 0.42 (1/2.4).
Actual sRGB formulas:
V = 1.055*(L^0.42) - 0.055
if L < 0.0031308: V = 12.92L
Technical Discussion » Face normals: 32-bit vs 64-bit
- axebeak
- 51 posts
- Offline
Well, yes, I think so.
I'm pretty sure that Houdini uses the following method to compute face normals: http://tog.acm.org/resources/GraphicsGems/gemsiii/newell.c [tog.acm.org]
If you look at the code above you can see all those expressions in the form (A - B) * (C + D)
32-bit build uses stack-based FPU. For 32-bit target such expression will be compiled into something like the following pseudo-code (it's kind of like RPN Calculator):
Push A
Push B
Minus
Push C
Push D
Plus
Multiply
Pop result
The stack-based FPU will carry out all the arithmetic operations above with 80-bit [en.wikipedia.org] precision (unless switched explicitly into low-precession mode).
64-bit build will use SSE scalar instructions for the same computations (FPU is deprecated in 64-bit mode). So intermediate results will have 32-bit precision (assuming float type at the source level).
Hence the extra precision in 32-bit builds.
Almost certainly, this phenomenon is not limited to just face normals. Not sure if there are any serious consequence to this (say, is it possible to construct a scene that will behave differently between 32/64-bit builds?), but this can be somewhat annoying in some cases… However, this is not a bug either.
I'm pretty sure that Houdini uses the following method to compute face normals: http://tog.acm.org/resources/GraphicsGems/gemsiii/newell.c [tog.acm.org]
If you look at the code above you can see all those expressions in the form (A - B) * (C + D)
32-bit build uses stack-based FPU. For 32-bit target such expression will be compiled into something like the following pseudo-code (it's kind of like RPN Calculator):
Push A
Push B
Minus
Push C
Push D
Plus
Multiply
Pop result
The stack-based FPU will carry out all the arithmetic operations above with 80-bit [en.wikipedia.org] precision (unless switched explicitly into low-precession mode).
64-bit build will use SSE scalar instructions for the same computations (FPU is deprecated in 64-bit mode). So intermediate results will have 32-bit precision (assuming float type at the source level).
Hence the extra precision in 32-bit builds.
Almost certainly, this phenomenon is not limited to just face normals. Not sure if there are any serious consequence to this (say, is it possible to construct a scene that will behave differently between 32/64-bit builds?), but this can be somewhat annoying in some cases… However, this is not a bug either.
Technical Discussion » Point indices for vertices along uv seams
- axebeak
- 51 posts
- Offline
Use VertexSplit SOP on you geometry for “uv” attrib, enable “Promote to Point Attribute”. Then just forget about vertices and work with points directly (in other words, after VSplit, Houdini points == Unity vertices).
Houdini Lounge » Game example
- axebeak
- 51 posts
- Offline
LyrThere is some new stuff in SVN, in particular, there are some examples on working with acceleration structures for collision detection.
I am curious if you have any more progress to show?
Here is Python script to generate and save bounding volume hierarchy (BVH) data for a collision model: gen_bvh.py [code.google.com]
I just uploaded a sample scene demonstrating how BVH can be built using Python SOP and stored with the geometry, this way it's possible to visualize the structure itself as well as collision queries performed against it.
This is demonstrated in the attached picture - wireframe shows the hierarchy of bounding boxes, the green thing is the query (directed segment), polygons highlighted in red are those to be tested against the query, gray polygons were discarded by the acceleration structure. The scene is here [kinnabari.googlecode.com].
Finally, HDK includes implementations of a number of suitable acceleration structures, namely BV_Tree subclasses. Instead of implementing your own BVH construction it's possible to use HDK classes for this. Here is the source code for a very simple HDK plug-in that uses GU_AABBTree to create BVH structure in SOP fully-compatible with the scripts above: SOP_BVH.cpp [code.google.com]
There is a number of things I'd like to demonstrate, e.g. custom controls to place gameplay-related triggers, lighting setup/export and so on, so I'm working on additional content necessary for these examples - this, well, will take some time.
Thanks!
Technical Discussion » Help with Making of "Power Plant"
- axebeak
- 51 posts
- Offline
It's something like this - see the scene. He first sets the red channel for the points to control the radius to something like (1-$BBY). Then there are two custom parameters “freq” & “amp” - see point2 SOP.
Houdini Lounge » Basic vops question
- axebeak
- 51 posts
- Offline
But surely attrib promote has to do some per-point attribute comparing of its own to determine the min and max values too?Attr promote iterates over points just once (N iterations). In VOP you will iterate over all the points for each point (N^2 iterations). That is assuming you're trying to iterate over the same points you're applying the VOP to.
You can connect a single point to the first input and loop over points in the second input, this will be probably comparable in speed to attr promote, the single point in this case is just a container for computed values.
Houdini Lounge » Basic vops question
- axebeak
- 51 posts
- Offline
This thread has some examples of both approaches, attrPromote->fit to range and loop over points in VOP:
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=23294 [sidefx.com]
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=23294 [sidefx.com]
Technical Discussion » Set display options with Python
- axebeak
- 51 posts
- Offline
hscript commands are available from Python, so this can be done with something like the following:
hou.hscript(“viewoptadd vector tu; viewoptset tu attrib(tangentu); viewoptenable * all +tu”)
hou.hscript(“viewoptadd vector tu; viewoptset tu attrib(tangentu); viewoptenable * all +tu”)
-
- Quick Links