edward

pbowmar
IMO it's a lot better to have an sRGB to Linear VOP node since your workflow

Wouldn't that cause incorrect mipmapping in sRGB space instead of linear?

We ran a battery of tests on this a year or so ago. And for some texture maps with a lot contrast it made a bit of difference in terms of luminance at the lower mip map levels, but in a lot of cases the difference isn't that noticeable.

So is it incorrect? Yulp. Is a huge issue, not really. As long as a couple of people know what's going on its not that bad.

Just curious, but which build type of Houdini are you using? Linux x86_64 gcc4.4? Linux x86_64 gcc4.1?

tamte
that's why it's called bitmask
thank you Wolfwood for posting this
i didn't think about it in binary form, it's all making sense now

Yea bitmasks can be quite handy. Sometimes I'll use them to speed up instancing. The more material overrides you have the slower instancing can become, so I'll collapse a bunch of toggles down into a single bitmask then override just that one parm. So 8 evaluations become just one, which has some impact when instancing 100,000 things.

jorosy
Thank you wolfwood for putting up that information.
Actually, I did came over that post before I asked.
I am not familar with api or c++ stuff, thus when I saw that number behind state, I thought it was memory address ??
Think I am wrong, if thaken out the ox code from number, it seems represents the pstate number.

They are just numbers. Pstate is handled with a bitmask.

http://en.wikipedia.org/wiki/Mask_(computing) [en.wikipedia.org]

The decimal representation of pstate hides all the neat stuff going on. If we look at it in binary we'll see a different story.


DYING
0x0002 (hex)
2 (decimal)
00000010 (binary)

STOPPED
0x0004 (hex)
4 (decimal)
00000100 (binary)

COLLIDE
0x0008 (hex)
8 (decimal)
00001000 (binary)

STUCK
0x0010 (hex)
16 (decimal)
00010000 (binary)


So if you want to have particle that has a shared state, say it just collided and is now marked for reaping (dying) you could have a dual state.

00000010 (dying)
OR 00001000 (collide)
= 00001010 (dying and colliding)

(or in decimal 10)


Why is the handy? Cause you can use logical operators to quicky get info.

Using the example above, I want to know if my particle is colliding, then you can do.

00001010 (your particle)
AND 00001000 (colliding state mask)
= 00001000 (non zero, thus TRUE)

So yes, your particle is colliding.

Another example, lets test if the same particle is stuck.

00001010 (your particle)
AND 00010000 (stuck state mask)
= 00000000 (zero, thus FALSE)

In this case, your particle is not stuck.

Looking at the numbers this way makes using VOPs to check for various particles significantly easier and faster.

Here is a couple of more.

http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=9839& [sidefx.com]

BDpro
how does softimage suffer on “defense” what exactly do you mean by that? it has great architecture, ice is incredible, great modeling tools, the animation tools are probably the best, and its integration with mental ray is pretty tight. so what does it lack?

Users with a sense of humor?

Mario Marengo
I don't think so….

And that's what I get for just skimming it. ops: Apologies for the misinformation.

Mario Marengo
I'm coincidentally in the middle of trying just that (for a Cook-Torrance based model) and it seems to be working pretty well so far (very efficient sampling), though I still have to tame some of the weights in the MIS portion :?

From what I gather (pun!) on reading the GGX paper, the BRDF component of the GGX BSDF is the same as the Cook-Torrance except they divide by 4 instead of a factor of PI.

The BTDF is a bit different tho. @Rtalz, do you guys use the full BSDF or just the BRDF component?

Usually local variables map to attributes on the geometry which means you don't have to do much work as bound attributes are available within VEX as long as you have a VEX parameter of the same name.

Currently its not possible to create BSDFs on your own, either via VEX or the HDK. There has been talk that in future versions of Houdini this may be possible but the VEX language itself would need to be improved in order to facilitate this.

The shading BSDFs are here
http://www.sidefx.com/docs/houdini11.0/vex/pbr [sidefx.com]

The full list is-

Shading BSDFs
ashikhmin
blinn
cone
diffuse
matchvex_blinn
matchvex_specular
phong
phonglobe
specular

Utility BSDFs
interpolate
lerp
switch

Wire/Curve BSDFs
wireblinn
wirediffuse

Volume BSDFs
isotropic
henyeygreenstein

If it's possible the end goal I want to reach would be to implement the ggx lighting model.

What's the ggx lighting model? Linky?

Right Click on the mantra node and choose Edit Parameter Interface. Its a spare parameter that isn't exposed by default.

Quad Core - Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz, Hyperthreading enabled.

OpenSuse 11.3, Houdini 11.0.542 (gcc.4.4 build)

8.5 minutes here.


cat benchmark.ifd | mantra
…
stuff
…
Render Time: 66:10.60u 25.41s 8:28.20r

rtalz
They are VERY similar. Only difference I know of based off limited info is that in PBR one ray will take into account one light source. Arnold takes into account more than one. Not sure if PBR is SIMD accelerated or not but Arnold is.

The default setting for Mantra's PBR rendering is to sample each light. You can switch it to sample just one light by turning off the Sample All Lights property. (This is new in Houdini 11.)

The forum might not be the best place for this type of question. I'd either email your account manager or better yet, support and they could provide you with a proper answer.

As far as I know, Houdini's expression language doesn't even have a int type. Its all floats under the hood.

Do the work in Python instead?



curse you mark. beat me by a minute

A singular matrix implies you have a zero scale. Most likely pscale is being set to 0 by some expression. (Ramping up or down in size over time.) If this is the case don't scale it completely to 0.

You can use the ‘ key to reorient the handle any way you like. Hit ’ again to reattach it to the geometry.

By default anisotropic directions are based off the geometry's tangents, (each face's s and t coordinate.) Unless you are dealing with NURBS or other parametric surfaces you are going to be at the mercy of each face's winding order.

Luckily the Surface Model VOP gives you a few options: Geometric Tangents, World Space, Object Space, UVs and Other.

For your model, setting it to Object Space and the Specular Anisotropy to -0.5 will give you an effect I think you are looking for.

For much more complex geometry or other effects its probably best to use UVs or some other attribute to drive the anisotropic coords.

ben simons
imho the work-arounds with wrappers and “test jobs” aren't production solutions.
1) There are over 200 binaries in $HFS/bin - would we wrap them all, for each release?

Awww. Wrappers are great production solutions. At least SESI seems think so.

~ $ cat $HFS/bin/houdini
#!/bin/bash

# Initialize application environment.
APP_DIR=$(dirname $0)
source ${APP_DIR}/app_init.sh ${APP_DIR}

# Now run the requested binary.
exec $0-bin “$@”



Instead of writing wrappers for everything, a launcher app could be written like, drd_launch hbatch. Depending on if a license was available it would either put you in the queue or launch whatever app your passed as an argument.

Long story short, SESI has stated that this isn't going to happen soon, if you need something now wrapper scripts or app launchers are just a few possible solutions.

rafal wisely
Another way is to have wrappers around hmaster and hbatch and have own control daemon manage the wrapper startup (given that the daemon can get the license count with ‘sesictrl -s’).

I agree with this approach.

FWIW, we used to have these kind of issues quite a lot, and not just with Houdini. In the end we wrote our own daemon manager which acts as a layer between the license servers and the apps. So when Houdini, Maya, Nuke, etc are launched its actually starting the app through our queue manager. That way we can see who or what is waiting for resources. Plus using a licensing middle manager for this you can give certain tasks/artists different license priorities.

TL;DR, I see this as more of a studio pipeline solution than a SESI thing. Because, no offense to SESI, no matter what they do, it won't be exactly what you want.