Hi all,
Hoping someone could help me with this predicament:
Im making an otl of an object that is textured and has its geometry captured with bones for deformation.
All the textures are embedded into the otl. They are then sourced through a copnet so that i can change colours with a flick of a switch on the otl, before then running through a custom shader in a shopnet at sop level.
The geometry is rigged and captured after all the texturing.
Everything is working as expected.
However, if i dont lock the capture node..transforming the object at object level is painfully slow as it re-cooks everything all the time. If i do lock it, it runs smoothly, until i load up the OTL in a new scene and the texture/shading information that takes place before locking the capture doesnt come through.
Im not sure how to deal with this. I assume I cant lock the texture/shading information and delete history? Even if i could, i doubt i would be able to in my otl as the texture runs through Cops for a colour change.
Im wondering what i should do? Is there any way around this happening?
Any advice would be gratefully received.
Cheers
J
Full Version: OTL: Textures dont load up after geometry capture locked
Well, I´m not sure how you´ve got it set up, but one thing to be wary of is referencing COPs directly in shaders.
What happens is, if you reference a COP, the image gets saved _into_ the IFD file, and gets saved an old, 8 bit .pic format, which means Mantra won´t render it effeciently, or with the ability to filter.
It´s handy for testing, but really should not be used for final renders.
Having said that, I suspect that when you lock the Deform, and then the IFD renders, it cannot recook up past the Deform, and therefore doesn´t ¨find out¨ about the COP net. I think )
Cheers,
Peter B
What happens is, if you reference a COP, the image gets saved _into_ the IFD file, and gets saved an old, 8 bit .pic format, which means Mantra won´t render it effeciently, or with the ability to filter.
It´s handy for testing, but really should not be used for final renders.
Having said that, I suspect that when you lock the Deform, and then the IFD renders, it cannot recook up past the Deform, and therefore doesn´t ¨find out¨ about the COP net. I think )
Cheers,
Peter B
hi pete
thanks
i just ran a small test otl which mocks up the same situation and so far it does appear to be the copnet that was causing the problem. If the texture goes directly to the shader i dont seem to have the problem, although im yet to try it on my main otl.
I find it a shame that you shouldnt and cant really reference textures through cops. To me that seemed the ideal way to link everything up in houdini - where i could make live changes to my textures - hue, saturations - all sorts of cool compositing stuff - before they went into the shader.
How else could i do something like this- allowing for an interactive switch on the otl to do stuff like that (change colours etc).
Im sure I could make a new shader in vops that has that kind of functionality option to adjust texture qualities - but doing it through cops seemed a tidier, faster and more accesible way of doing it for an otl.
thanks
i just ran a small test otl which mocks up the same situation and so far it does appear to be the copnet that was causing the problem. If the texture goes directly to the shader i dont seem to have the problem, although im yet to try it on my main otl.
I find it a shame that you shouldnt and cant really reference textures through cops. To me that seemed the ideal way to link everything up in houdini - where i could make live changes to my textures - hue, saturations - all sorts of cool compositing stuff - before they went into the shader.
How else could i do something like this- allowing for an interactive switch on the otl to do stuff like that (change colours etc).
Im sure I could make a new shader in vops that has that kind of functionality option to adjust texture qualities - but doing it through cops seemed a tidier, faster and more accesible way of doing it for an otl.
Hi …
..just to update, ive got my otl working as i originally wanted.
Basically, i slapped the otl into a new scene, allowed editing of contents, unlocked the capture nodes and relocked them again.
The textures reloaded…i then resaved the OTL.
Now everytime i pop the otl into a new scene it works great - i had been doing this with my original OTL scene - but it never worked when loading into a new scene.
I dont know why this has now worked by editing the OTL once a new scene and resaving out.
I also still have the switch that is linked to the copnet - allowing me to choose colours from adjustments to the one texture etc - and it works really great for what i want.
….but to continue on with my questions in above post - as I am using .tiff format and not .rat for my textures - would putting the textures through the copnet really be losing anything anyway?
Dont the filtering possibilites, that i essentially lose when putting through a copnet only occur when using .rat?
Also, as already asked - im keen to know if there is any other way of doing what i want without using a copnet? It just seems such a great way to wire things through the network to me. From the one texture I can mask off bits and change colours and stuff in cops - add switches - and then reference to a shader. The switches are then on the otl controls - and i can make quick changes all from the one texture.
Am i mad to do this? (normally am) - is there a better way
:?:
J
..just to update, ive got my otl working as i originally wanted.
Basically, i slapped the otl into a new scene, allowed editing of contents, unlocked the capture nodes and relocked them again.
The textures reloaded…i then resaved the OTL.
Now everytime i pop the otl into a new scene it works great - i had been doing this with my original OTL scene - but it never worked when loading into a new scene.
I dont know why this has now worked by editing the OTL once a new scene and resaving out.
I also still have the switch that is linked to the copnet - allowing me to choose colours from adjustments to the one texture etc - and it works really great for what i want.
….but to continue on with my questions in above post - as I am using .tiff format and not .rat for my textures - would putting the textures through the copnet really be losing anything anyway?
Dont the filtering possibilites, that i essentially lose when putting through a copnet only occur when using .rat?
Also, as already asked - im keen to know if there is any other way of doing what i want without using a copnet? It just seems such a great way to wire things through the network to me. From the one texture I can mask off bits and change colours and stuff in cops - add switches - and then reference to a shader. The switches are then on the otl controls - and i can make quick changes all from the one texture.
Am i mad to do this? (normally am) - is there a better way
:?:
J
I wonder if the best solution to this is to create composite ROPs for each of your textures, which generate the .rat files on disk (then reference these in the shaders). With a ROP network it should be possible to set it up to render the textures and then proceed with the mantra render.
This should not be much different than what is actually happening with the direct COP references, except that your ifd won't be polluted with binary image data and you'll get the advantages of the .rat disk file images (mipmaps, tile caching, and filtering).
Andrew
This should not be much different than what is actually happening with the direct COP references, except that your ifd won't be polluted with binary image data and you'll get the advantages of the .rat disk file images (mipmaps, tile caching, and filtering).
Andrew