Jump to content


Popular Content

Showing most liked content on 03/27/2017 in all areas

  1. 1 point
    Hello, please, I would like to achieve this kind of effect in my production: I am a freelancer, I have Houdini Indie and four computers (one 6core and three 4core-i7). I do jingles for local event agency. The projects I do are quite low-budget and deadline is in a week or two usually. I had to do this in a week, so I have used my C4D https://vimeo.com/186295732 Now I am more and more using Houdini. Please, would you be so kind and direct me to a solution? A] Mantra superfast shader (fake) It doesnt have to be photorealistic - points do not emit light, but they reflect on surfaces. Can I get under cca 2 seconds for such glowing line (A-reference), fullHD frame, on my local CPUs? Should I "clone" points onto the line? Can I set the blending mode of the points to be additive? Can I set the fuzzines of a point by custom gradient (radial from center of the point)? Btw can I set the alpha of a point with bitmap, for example small earths? For further development, I want to go this way: B] Mantra semi-physical shader Is it possible to get under cca 10 sec render time, with this: - fake depth of field (for example by setting the radius bigger and darker) - fake interacting with volumes (bigger radius, darker) - can I somehow fake, that points are emitting light? Maybe by some proximity shader on the "rigid" objects or volumes? This is beautiful: https://www.instagram.com/rbrthrsk/ C) Gpu renderer? Should I go for some GPU renderer? I like mantra very much. This is done with the Redshift https://www.artstation.com/artwork/XOKQn
  2. 1 point
    ha! True to that. I didn't think about that, still though excellent resource!
  3. 1 point
    Yep, you could run a bunch of them in 16x mode, and have some lanes leftover to access a couple of PCI-Ex-based SSDs for large datasets. This is particularly important as AMD GPUs now have virtual addressing which could target the data on SSDs directly (though I'm unsure if that's currently supported for external SSDs, or just the TB one built in to the new Radeon Pro SSG cards). Usually there's a few lanes taken up by ethernet, the chipset, and slow storage as well, so 40 can go really quick.
  4. 1 point
    Naples is targeting supercomputing and massively parallel applications (Mantra and other renderers are definitely in this category). It will be especially useful for OpenCL and CUDA with 128 PCI Express lanes, that's crazy. The Xeon E5-2600 series has 40 PCI Express lanes. It may or may not make a good workstation platform depending on how much stuff you do that relies on a single processor core. These days that's less and less common but there are some applications that lag in various areas. It will likely make a good render node and simulation node if their pricing is competitive like the Ryzen products.
  5. 1 point
    I wrote a skin shader recently and just released it on orbolt: http://www.orbolt.com/asset/_danylyon::PBR_skin (There's also a demo video) It's written in VEX, check out the help card with lot's of informations. The features are: Direct (single) SSS, optimized for skin. SSS from indirect sources for extra realism. optimized values for white skin and red blood, possible to change to black, green.. any color. Adjust absorption and depth of the SSS. Color correction of the skin maps. Add Skin, dermis and deep maps. Map to mask back scattering. Oily specular layer. Fine sparkle effect from microgeometry. Sheen, fuzzy layer. Displacement (b/w, vector space and tangent space). Shadow shader for colored shadow rims. Extra output variables: SSS, dermisSSS, deepSSS, backSSS. Output of Z (depth), uv, normal, position and velocity. Support for UDIMs. Attached are some WIP.
  6. 1 point
    great suggest farmfield, i really appreciate it. here finally i got a works setup about cloth to particle conversion here'some hint about my personal project looks like.
  7. 1 point
    Stu already posted the ultimate glass shader, but I thought it might be fun to try it the old fashion way, just for giggles I'll spread this over several posts so I can add bits and pieces as I find the time to work on them. I have a bunch of code lying around that deals with glass, but since I'm sharing, I thought I'd take the opportunity to rethink the whole thing from scratch, and post as I build it. That way we can also discuss each step separately and critique the choices made along the way. Requirements: A complete glass shader should support the following optical properties: reflection, refraction, transmission, absorption, and dispersion (did I leave anything "visible" out?). All these effects are wavelength-dependent, so there's a big choice to be made along the way regarding the potential need for a spectral color model. This hypothetical "complete" model would be relatively expensive to compute (in *any* renderer) and clearly "overkill" in many situations (e.g: glass windows), so we'll need the ability to turn features on/off as needed (or end up with several specialized shaders if we can't keep the full version both flexible *and* efficient). Space: It is customary to do all reflectance calculations in tangent space, where the x and y axes are two orthonormal vectors lying on the plane tangent to the shade point "P", and z is the unit normal to that plane. This simplifies some of the math and can therefore lead to more efficient code. However, since both VEX and RSL provide globals and runtime functions in some space other than tangent ("camera" space for those two), working in tangent space will inevitably mean some transformations. Whether working in tangent space is still advantageous after that, remains to be seen. As a result, we'll need to look at the costs involved in writing our functions in either space, and base our final choice on what we find. Naming Conventions: I'll adopt the following naming conventions for the main variables: vector n - unit normal to the surface vector wi - unit incidence vector, points *toward* the source vector wo - unit exitance vector, points *toward* the observer vector wt - unit transmission direction [float|spectrum] eta_i - index of refraction for the incident medium [float|spectrum] eta_t - index of refraction for the transmissive medium (glass) [float|spectrum] kr - fraction of incident light/wavelength that gets reflected [float|spectrum] kt - fraction of incident light/wavelength that gets transmitted All angles, unless otherwise stated, are in *radians*! All vector parameters, unless otherwise stated, are expected to be normalized! Fresnel: This is the workhorse for glass, it alone is responsible for 90% of the visual cues that say "glass". The Fresnel functions determine the fraction of light that reflects off a surface (and also the fraction that gets transmitted, after refraction, *into* the surface). Glass is a "dielectric" material (does not conduct electricity), so we'll use that form of the function. We'll also ignore light polarization (we're doing glass, not gems... a full model for gem stones would need to take polarization into account). But wait! both RSL and VEX already *have* this kind of fresnel function, so why re-invent the wheel?!? Implementations are all slightly different among shading languages. Having our own will hopefully provide a homogeneous (actually, we're shooting for "identical") look and API across renderers -- if we find the renderer's native fresnel is identical to ours we could always choose to switch to the native version (which is usually faster). The following is, to the best of my knowledge, an accurate Fresnel implementation in VEX for dielectrics (unpolarized). In case we find it useful at some point, I give it for both "current" space (camera space for VEX and RSL), and tangent space. Here's the fragment for world space: // Full Fresnel for dielectrics (unpolarized) //------------------------------------------------------------------------------- // world space void wsFresnelDiel(vector wo,n; float eta_i,eta_t; export vector wr,wt; export float kr,kt; export int entering) { if(eta_i==eta_t) { kr = 0.0; wr = 0.0; kt = 1.0; wt = -wo; entering = -1; } else { float ei,et; // determine which eta is incident and which transmitted float cosi = wsCosTheta(wo,n); if(cosi>0.0) {entering=1; ei=eta_i; et=eta_t; } else {entering=0; ei=eta_t; et=eta_i; } // compute sine of the transmitted angle float sini2 = sin2FromCos(cosi); float eta = ei / et; float sint2 = eta * eta * sini2; // handle total internal reflection if(sint2 > 1.0) { kr = 1.0; wr = 2.0*cosi*n - wo; kt = 0.0; wt = -wo; // TODO: this should be zero, but... } else { float cost = cosFromSin2(sint2); float acosi = abs(cosi); // reflection float etci=et*acosi, etct=et*cost, eici=ei*acosi, eict=ei*cost; vector para = (etci - eict) / (etci + eict); vector perp = (eici - etct) / (eici + etct); wr = 2.0*cosi*n - wo; kr = (para*para + perp*perp) / 2.0; // transmission if(entering!=0) cost = -cost; kt = ((ei*ei)/(et*et)) * (1.0 - kr); wt = (eta*cosi + cost)*n - eta*wo; } } } The support functions like cosFromSin() and so on, are there just for convenience and to help with readability. These are included in the header. After some testing, it looks like VEX's current version of fresnel() (when used as it is in the v_glass shader) and the custom one given above, are identical. Here's an initial test (no illumination, no shadows... this is just a test of the function). Yes, you'd expect the ground to be inverted in a solid glass sphere. The one on the right is a thin shell. I ran a lot of tests beyond that image, and I'm fairly confident it's working correctly. The first thing that jumps out from that image though, is the crappy antialiasing of the ground's procedural texture function for the secondary rays. In micro-polygon mode, you'd need to raise the shading quality to 4 or more to start getting a decent result... at a huge speed hit. It looks like there's no area estimation for secondary rays in micropolygon mode. In ray-tracing mode however, things are good -- whether it uses ray differentials or some other method, the shader gets called with a valid estimate and can AA itself properly. The micropolygon problem needs to get looked into though. You would expect the built-in version to run faster than the custom one, and it does (~20% faster)... as long as you keep the reflection bounces low (1 or 2). As the number of bounces increases, our custom version starts out-performing the built-in one. Yes, this is weird and I very much suspect a bug. By the time you get to around 10 bounces, the custom code runs around 7 times faster (!!!) -- something's busted in there. OK. That's it for now. It's getting late here, so I'll post a test hipfile and the code sometime soon (Monday-ish). Next up: Absorption. (glass cubes with a sphere of "air" inside and increasing absorption -- no illumination, no shadows, no caustics, etc)
  8. 1 point
    This thread could help you http://forums.odforce.net/index.php?/topic/15419-flip-viscosity-driven-by-age/#entry95128 the main goal is to modify the FLIP source to add birth attribute ( value $T) Then you can use this attribute in a sopsolver.
  9. 1 point
    Depends if you want the un-shared edges or all edges, but the method is the same.. For un-shared edges add a Divid SOP and turn on Remove Shared Edges (turn off Convex), for all edges skip this step. Add a Polywire SOP (set the radius to 0.0) Add a Group SOP, set Operation to Group by Range Add a Blast SOP for that group1 Add another Group SOP, set Operation to Group by Range Add another Blast SOP for that group1 Add a Fuse SOP (turn off Degenerate) And your done.