Search the Community

Hi I've been playing around with the wdas data set cloud and I've noticed that we houdini users (who are not lucky enough to have access to shaders dveloped by giant companies) lack an overall dense (almost pyroclastic) cloud shader that shows the distinct features of puffy cumulus clouds. After a through searching both in web and odforce i've seen that a few people also inquired on the same subject but it was inconclusive. I've decided to use this post as an idea dump to possibly implement a new shader or track your opinion on the subject. During the searching i've realized that distinct features of dense clouds are achievable by either using a very high number of internal light bounces or by faking them. I have seen that dark edges are the most prominent feature of the dense clouds since the other effects as transmittance and high forward scattering are already studied and implemented in shaders. To assess the current state of volume rendering other then mantra i've done a couple tests with several renderers in maya and also tried the new terragen 4.2. The most beautiful (simulating a real cloud light) is the hyperion render. Terragen 4 clouds are also very realistic and detailed (http://terragen4.com/first-look/). Arnold seems to be the best commercial option out there and is very good in giving the edge darkening but fails at details in dark areas (which is highly visible in hyperion) but i think these areas can be compansated with additional ligths. Redshift render is blazing fast but no where near the realism. In houdini i have used pbr with 50 volume limit, 5x5 samples, volume quality at 2 with a standart volume cloud shader. I have just started to see dark edges but even rendering a very small portion of 1920x1080 image took me about 10 minutes ( 2xE5-2680 v3, 48 cores total) . For speed comparison, redshift was the fastest with a couple minutes, arnold took about 10 minutes, terragen is said to be around an hour for a very heavy cumulus cloud. No information about hyperion but since wdas has a 50.000 core farm it shouldn't be a problem. Mantra was the worst with a projected couple hours of total render. Below are the sources i found for future reference for myself Oliver also asked about a cloud shader and Mike Lyndon says he has implemented a shader before (https://forums.odforce.net/topic/17900-cloud-shader/) . This is the most prominent one and is the one i will be implementing. The thesis of Antoine Bouthors that Mike says he has implemented (http://evasion.imag.fr/~Antoine.Bouthors/research/phd/thesis/thesis.pdf) . Beautiful mie scattering solution by Matt and the base for my shader (http://mattebb.com/weblog/rendering-clouds-with-the-mie-phase-function/) Odforce user Andrea was also interested in such topic and has some ideas in it (https://forums.odforce.net/topic/24831-cloud-shader/) Modelling aspect of clouds (https://forums.odforce.net/topic/12923-pyroclastic-noise-demystified/?page=2) Siggraph presentation by Magnus Wrenninge (http://magnuswrenninge.com/content/pubs/VolumetricMethodsInVisualEffects2010.pdf) Realtime clouds for horizon zero dawn by guerilla games. realtime but has really nice implementations (horizon zero dawn real time clouds) A hefty paper from Hyperion developer Yining Karl Li (https://blog.yiningkarlli.com/2017/07/spectral-and-decomposition-tracking.html) With the directions i gathered from Mike Lyndon's post i have started implementing the photon map approach. I have already implemented a henyey-greenstein phase function and added the contribution by radiance photons. Now i will try to implement the ideas presented in the thesis of Antoine, with high focus on cumulus cloud rendering (ch. 7). Attached is the current state of shader (cloud_shader.rar) I am also interested in GLSL implementations for viewport and cloud modelling tools but i guess this post wil be mostly about a shop type implementation. anyway here is a simple glsl implementation work and i am open to every feedback https://forums.odforce.net/topic/32197-glsl-pipeline-in-houdini/?tab=comments#comment-190945 I am definitely not an expert on this subject, so all input, ideas, criticsm, and source is welcomed. Thank you. Hyperion Render (wdas_cloud_hyperion_render.png is Copyright 2017 Disney Enterprises, Inc. and are licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License ) Terragen 4 Render terragen_4_render.tif Houdini Pbr Render (the little part on top took 10 minutes to render so i left it unfinished) Arnold Render Redshift Render

Hi everyone! In GLSL they use this function called "step" that generates a step function by comparing two values. Is there any alternatives in vex ?

Hello, I would like to experiment with GLSL shaders in Houdini viewport a bit, but I had very little success yet As a simple thing I would like to create a "matcap" shader, I have this shader in mantra and it works well, but it is quite simple logic in it and I would like to try it out in GLSL as well. I tried two approaches for creating glsl shaders: New Operator Type - SHOP Type - GLSL Shader This approach does not give me any results, the default shader has quite complex code and in the viewport I can see only white color. I tried to modify couple of variables in the code to at least change color from white to red, but unsuccessfully Reference ogl_glsl_shader parameter on a shader pointing to shader.prog file which references to shader.frag and shader.vert This gives me results in the viewport and works quite well, however I do not know how to reference node's parameter value to the GLSL variables. I created those files based on examples in $HFS/houdini/glsl //fragment shader in vec2 matUv; out vec4 color; uniform sampler2D tex; void main() { vec3 base = texture2D( tex, matUv ).rgb; color = vec4( base, 1. ); } First question: how can I reference parameter on the node to the tex variable in opengl? When googling I found some examples which implied that only creating string parameter tex should work, but when running their example files I never got any result in the viewport. Second question: is this the correct workflow? How could I achieve the same thing with New Operator Type workflow? Do you have some simple examples of those nodes with basic shading? E.g. sampling a texture, using constant color... Thanks for any clarification, Juraj

Hi guys, Just want to showcase our work in progress and ask everybody's opinion. The demo is HERE. In short, were able to transfer Houdini vertex animation to a Web Browser. To accomplish that we used Houdini texture cache tools, 3js library, and tinyexr loader which was compiled to JavaScript. We are exited about the result and looking for a project to apply it. Kirill and Snay

I'm attempting to write a custom GLSL shader for the viewport to aid in the development of a game that will have a toon shaded style (following some ideas from this Guilty Gear Xrd talk from GDC). I want to end up with the same shader applied in the viewport as the shader that will be used in the game to make the modeling and texturing pipeline easier. I'm new to GLSL and learning by experimenting as I go. I've been able to hardcode a simple directional light in the fragment shader that is relative to the viewport by using a vec3: if (dot(nN, lightDirection) < 0) { lspec = vec3(1.0); } else { lspec = vec3(0.0); } (I'm using lspec to test the formula at this point, because it's on the top layer.) The next step is to pull the lightDirection from a Houdini light instead of hard coding it. This is where I'm running into some problems. There are two sources of documentation I've found: http://www.sidefx.com/docs/houdini15.0/shade/opengl http://www.sidefx.com/docs/hdk15.0/_h_d_k__viewport_g_l3.html The first says to use light uniform blocks like this: layout(std140) uniform light0 { vec3 pos; vec3 dir; vec3 atten; vec3 amb; vec3 spec; vec3 diff; float coscutoff; bool point; } lightSource0; When I use this, and try to get lightSource0.pos, the model goes black and has no lighting applied. I'd like to query this variable to debug it, but I'm not sure how to do that within GLSL itself. The second source of documentation uses a slightly different variable: layout(std140) uniform glH_Light0 { vec3 pos; // light position, world space vec3 dir; // light direction, world space vec3 atten; // attenuation - .x: d^2, .y: d, .z: const vec3 amb; // ambient color component vec3 spec; // specular component vec3 diff; // diffuse component float coscutoff; // cosine(cutoff) to compare to dot(dir,P-pos) bool point; // point light (true), spot light (false) } lightSource0; When I use this code, the shader fails to compile and says "ERROR: Multiple definitions of interface block 'glH_Light0' differ in name/type/order/qualification of members". Because of this error, I think that the glH_Light0 name is the correct one to use, but I'm not implementing this correctly. I've looked for more documentation on this, but have come up dry. Does anyone know how to properly reference lights in GLSL? I appreciate any help or insights.

This seems like a very basic question and is related to GLSL, so I don't know if this is the right corner of the forum. I have a simple working GLSL shader that pulls in the uv attribute. This is the Vertex Shader: #version 150 in vec3 P; in vec3 N; in vec2 uv; out vec3 vPos; out vec3 vN; out vec2 uvCoords; uniform mat4 glH_ObjectMatrix; uniform mat4 glH_ViewMatrix; uniform mat4 glH_ProjectMatrix; uniform mat3 glH_NormalMatrix; void main() { vPos = vec3(glH_ViewMatrix * glH_ObjectMatrix * vec4(P, 1.0)); vN = normalize (glH_NormalMatrix * N); uvCoords = uv; gl_Position = glH_ProjectMatrix * vec4(vPos, 1.0); } Fragment shader: #version 150 uniform sampler2D t_diffmap; in vec3 vN; in vec2 uvCoords; out vec4 color; void main() { vec3 diff; diff = texture(t_diffmap, uvCoords).rgb; color = vec4(diff,1.0); } Now, this works with point UVs. If my UVs are of vertex type, this does not work any more (the shader shows a single color only). Since 99% of my meshes will be vertex UV, I am seriously wondering how I get access to them in the GLSL shader... Any help is appreciated! Thanks in advance Johann