Hi guys,

I'm really new to Houdini and am tying to understand as to why some materials (ie the bricks preset material)
are capable of displaying textures on objects in the viewport, while textures I attach to the principled shader
will not display them. I tried both referencing the texture via the built-in string texture parameters as well as connecting a texture node to the base color input, and both approaches work and render fine in any renderer, but I will never see the texture in the viewport. Am I missing any crucial steps (yes, I did read the documentation on texturing, as well as the principled shader, and watched half a dozen tutorials on shading, and yes, the object has UVs), or is this “by design”?

Any pointers in the right direction (or a link to a section of the docs I might have missed) are highly appreciated.

Cheers,

Stefan

PS: Oh, and sorry for the stupid user name, thats what you get when you log in via google.

Use the texture path parameters on the texture tab of the principled shader. These parameters have already been tagged as parameters for viewport display.

Thx jsmack, that actually works! It's just not what I want and need most of the time. For example, wrapping the principled shader (and, potentially, other nodes) in a shaderbuilder (I read that is “tidy” and a good habit) and assigning that to the object disables texture display again (it still renders fine in Mantra though).
And sometimes I just need to connect a texture node (and maybe some other nodes in between for e.g. color correction and/or blending with other textures), so I can't directly use the texture path parameter.
I admit I feel like a total noob. Creating a sphere and have a texture node attached to a shader which I want to display in the viewport is what has taken me 10 seconds to do in pretty much any application I have ever opened for the first time in my life since I started out in CG (in 1993). And here I am failing for several consecutive days in a row on such a seemingly simple task. Is it me?

Hi, as a new Redshift user, I'm in the process of editing the Redshift Material Builder (mainly for imported Substance Painter textures) and have encountered some viewport issues too.

I've not had issues with the Principled shader in the viewport but when I collapsed it into a Material Builder, nothing comes through to the viewport. I expect there is a simple solution to this but I'm not sure what it is.

I have attached a hip file and have a few questions that might help us both…

RS_Shader
1. OpenGL Diffuse map - All maps except diffuse will display in the viewport. When editing Parameter Interface/Rendering Parameters, I was able to find the other maps easily. For diffuse however, I could only find the Diffuse Texture Layers, Texture # (ogl_tex#) and I'm fairly certain this is the reason it's not displaying correctly. (I was expecting to find a ogl_diffuse_map or something similar to the others so I'm not sure how to use it)
Fixed by using Diffuse Texture Layers folder.

2. Roughness & Metallic map - Something needs to be added after the maps before they connect to the RS_Material to convert, if necessary, into a Float. I tried a few different things but couldn't get it right. I can use grayscale textures but I'd still like to know what the correct method is.

3. Texture maps problem - I would like to leave the Filename blank if it's not needed. ie. for Opacity, it should be a default of white (or whatever opacity value is chosen) when no texture is applied. Currently, if no texture is applied, it reads as black.

4. Related to (3) - The Principled Shader has specific texture inputs, whereas this shader doesn't so when I plug in the Diffuse texture, it overrides (greys out) the Diffuse color. The Texture Sampler has a Color Multiplier but without a texture, it has same issue as (3). The same is true for all other maps so I've stopped progress here because I'm clearly missing something.


Notes for hip file:
- I have added a material switcher to the grid. (called “Select Material”, located on the Render tab, just above the Material path) 0= Redshift, 1= Principled, 2= Principled Build
- Currently, only the Principled will display diffuse map in viewport. RS_Shader & Principled work in viewport.
- The Principled Build was made by selecting the Principled Shader and using “Collapse Selected into Material”.

Rob

Edited to show fixes in new hip file

stefan05e81cea6f0b4809
Thx jsmack, that actually works! It's just not what I want and need most of the time. For example, wrapping the principled shader (and, potentially, other nodes) in a shaderbuilder (I read that is “tidy” and a good habit) and assigning that to the object disables texture display again (it still renders fine in Mantra though).
And sometimes I just need to connect a texture node (and maybe some other nodes in between for e.g. color correction and/or blending with other textures), so I can't directly use the texture path parameter.
I admit I feel like a total noob. Creating a sphere and have a texture node attached to a shader which I want to display in the viewport is what has taken me 10 seconds to do in pretty much any application I have ever opened for the first time in my life since I started out in CG (in 1993). And here I am failing for several consecutive days in a row on such a seemingly simple task. Is it me?

If you build your own shader out of nodes, then it won't affect the viewport. The opengl shader doesn't know about the mantra material network, so there's now way for the viewport to know what textures go with with properties. The texture node, or surface color, is just a mantra node, it doesn't have any significance to the opengl shader. Only parameters on the node which is applied as the shader inform the opengl shader. They do so using tags. If you promote the texture path parameter on the surface color node, you can add a tag to the parameter to associate it with the opengl parameter.

http://www.sidefx.com/docs/houdini/shade/opengl#gl_tags [www.sidefx.com]

Thank you guys,

So far I have understood that in order to have a specific texture displayed in the viewport one has to promote and tag the texture path parameter with the corresponding OGL flag so the Realtime shading backend understands what to do with it, and that it's particularly difficult to maintain those parameter promotions and tags when nesting shading nodes in other networks (e.g. wrapping shading nodes in a Material Builder), as illustrated by the principled shader loosing ability to render the base color texture in the viewport even when the stock texture path parameter is used to reference a file texture instead of connecting a file texture node to the base color parameter.

If above written is correct I think this is a very fragile system with a lot of room for improvement. An example of a paradigm that was very easy and reliable was the way XSI handled texture display in the viewports on a per material basis by letting the user choose which of the textures used in the respective material to use as the diffuse/base color texture on the Realtime representation of it. This could be exposed as a separate tab hosting parameters (a pulldown menu) to let the user choose what texture to use and should automatically be set correctly when a shading network is wrapped in a Material Builder. This could be improved further by allowing the user to not only specify the base color texture but others like normal and roughness maps as well, to name just the most important ones.

Update: After looking at the linked hiplc file I get the impression that we are on the same page there Rob!

In addition, it would be cool to be able to use custom GLSL shading code via a dedicated realtime shader (if there is not already such a thing? (EDIT: scratch that, I just found it), as well as support for procedural texture display in the viewports (3dsMax has this, and I believe so does Blender - super useful).
I think it would not even need to cover more than the basic 0,0-1,1 uv space since whats most important with procedural textures is their size and principle structure relative to the shaded object, and that can be assessed even with texture seams in place (e.g. for parts of the mesh that are mapped to areas outside the 0,0-1,1 uv space and in case the proc. texture does not tile). My 5 cents.

Should we create RFEs for these?

Cheers,

Stefan

If above written is correct I think this is a very fragile system with a lot of room for improvement.

Maybe an adjustment in workflow might be a good approach?

Instead of trying to set up the viewport to display everything, just tab to the render window that's set up with the same camera as viewport and render the scene to give you an idea of where your at in your work in terms of shading.

BabaJ

If above written is correct I think this is a very fragile system with a lot of room for improvement.

Maybe an adjustment in workflow might be a good approach?

Instead of trying to set up the viewport to display everything, just tab to the render window that's set up with the same camera as viewport and render the scene to give you an idea of where your at in your work in terms of shading.

I wouldn't expect it to render “everything” (not even sure if the base color textures qualifies as “everything”), but at least the most important aspects of a scene (important lights, shadows, and said base color texture), and it seems this is what is being attempted, looking at the existing core functionality, it's just that these features fail to work in some cases, or are difficult to maintain.
In general, I agree to above suggestion - there might be some cases in lightweight scenes that render fast where repeated preview rendering could be an option, yet I think the general concensus is that it's usually too slow and expensive, i.e. not interactive enough. Esp. in early stages of production you just want to render a quick flipbook (one that takes 30 seconds to render from the viewport) to quickly get something to show and get approved, instead of kicking of a full-on render that can take anything from 30 minutes to days.

Hello, just wanted to know if viewport representation of textures and materials is still so difficult to archive. In my opinion if Sidefx wants to make Houdini more accesible to more people this is a main topic where put some resources in.

Well in some cases the USD preview materials are automatically generated, which helps. And if you use /stage context you can set a Karma viewport with very low samples for quick preview.

Besides that, nothing really changed afaik. The Houdini's default viewport is a rather simple GLSL shader. It has absolutely nothing to do with Mantra/Karma/Redshift, and therefore it can't understand their materials.

Edit: I did more research. GL viewport shaders actually get their data from OpenGL parameters, which can be set up manually.

I don't think there is a way to automatically fill out these parameters, but they can refer to other nodes, just like normal Houdini parameters do. For example, you can make the OpenGL texture parameter refer to the Texture node's path parameter.