Sop_shopattrib

[Wolfwood]

Here is something for the SourceForge od[force] project....(just so its not empty)

This is more of a self tutorial than it is useful. Its a SOP that takes a SHOP as a parameter and then adds all the SHOP's parameters as Attributes to the SOP. This might be useful for RenderMan users. Apply one shader to the geo at the object level then plop down a couple of these things to control the shading on a per primitive (or detail) basis instead of having to use tons of Shader SOPs which each add a RiShader call.

I'm not much of a C++ coder so if I did something to make you cringe let me know so I can fix it.

Comments and documentation are left as an excercise for the reader

SOP_ShopAttrib.tar.gz

[Wolfwood]

Small follow up....

(Motivation)

One of the annoying things about PRMan is that it never frees memory from RiShader calls. So if you have tons of large shaders and even if all the geo that was attached to those shaders has been rendered/culled it will still hold onto the memory allocated for the RiShader's data structure. When you have lots of big shaders you can run out of memory pretty fast. One area that can be cleaned up is Geo objects.

For example- Sometimes you have a single Geo object with tons of groups inside of it and a Shader SOP applying the same shader with different parameters to the shading groups. (Texture maps etc). This results in a lot of Shader calls inside the RIB stream which hang around until the end of the render. So the trick is to apply the shader at the object level then make the parameters, which are different from group to group, attributes of the geometry. This will result in larger RIBs but this memory will get freed along with the rest of geo.

[Jason]

Nice one! Specialized but handy when you need it. So, do you want to add it? I can add you as a project member if you tell me your sourceforge name.

http://www.odforce.net/wiki/index.php/SourceForgeProject

[Wolfwood]

Nice one! Specialized but handy when you need it. So, do you want to add it?  I can add you as a project member if you tell me your sourceforge name.

http://www.odforce.net/wiki/index.php/SourceForgeProject

18969[/snapback]

It definitely is a more specialized SOP...which is why its more of a tutorial than anything else.

shadeops is my SF name.

I can add it...but my SF experience is null. Then again it can't be worse than Houdini.

[Jason]

thou art hereby added.

good luck! we're cheering from the sidelines.

[thekenny]

that's pretty sneaky jim

don't tell me you only thought about that now....

-k

[Jason]

I uploaded your other one to sourceforge - should I do this one too?

It's not tricky - its ftp'ing it to upload.sourceforge.net/incoming and then "Admin>File Releases" to add a package and comment, etc.

[Wolfwood]

that's pretty sneaky jim

don't tell me you only thought about that now....

-k

18990[/snapback]

hehe it was born as a result of the crowd shader memory problems back at the start of the year. After we found out that was what was causing the memory limit core dumps we brain stormed a couple of different solutions and ultimately it was decided we would just limit the number of characters per layer. Althought I really wanted to do the attribute based approach it was too late/too expensive to change that part of the pipeline.

But me being me....I stopped playing City of Heroes for a week or so and did it anyway. And it has been collecting dust ever since.

[Wolfwood]

I uploaded your other one to sourceforge - should I do this one too?

It's not tricky - its ftp'ing it to upload.sourceforge.net/incoming and then "Admin>File Releases" to add a package and comment, etc.

18995[/snapback]

I think you'll have to. According to the Admin page...

# You are listed as a developer (not administrator) for this project.

# You cannot perform file release operations on this project.

# You cannot manage documentation (in DocManager) for this project.

# You cannot moderate forums for this project.

Should the packages be also tagged with a Houdini version number? I know between major versions things can break/header files get rearranged etc.

[Jason]

I think you'll have to.  According to the Admin page...

Should the packages be also tagged with a Houdini version number?  I know between major versions things can break/header files get rearranged etc.

18998[/snapback]

Ok, try again; I found permissions called "Release Technician" and switched it on.

As for version numbers, hmm. Perhaps these should be in the release notes? Some plugins never need changing and some need rebuilding even across minor builds.

Also, binaries - particularly for Windows people who dont have a compiler installed. I'll look into that.

[Jason]

So for binaries, we could add a file to the release and use a naming convention like:

CMD_chopls-1.0-houdini7.0.231-linuxrh9.gz

..and make sure that it's "type" is set to ".gz" or maybe even "Other Binary Package" maybe - even thought its not a real package?

[Wolfwood]

So for binaries, we could add a file to the release and use a naming convention like:

CMD_chopls-1.0-houdini7.0.231-linuxrh9.gz

..and make sure that it's "type" is set to ".gz" or maybe even "Other Binary Package" maybe - even thought its not a real package?

19000[/snapback]

Personally I think you should only provide binaries for Windows. Getting dev tools for Linux is easy. Plus i think there are at least 3 different gcc flavors of Houdini for Linux which means even more packages etc. Odds are if you are using linux compiling binaries shouldn't be problematic at all.

So....for one package you would have

CMD_chopls-1.0-src.gz

CMD_chopls-1.0-houdini7.0.231-winBinary.zip

CMD_chopls-1.0-houdini8.0.111-winBinary.zip

Or something like that.

On a side note....I don't think anyone other than the admin can add packages to sourceforge projects. I can modify packages....but I can't add new ones.

[Jason]

Sounds good to me...

I've added "Project Admin" permissions to you; try now..