3delight tests
Plugins linking to this thread: (hide)
Blob Strokes
Here's a small ICE compound used to generate these 'blob-strokes'. I had something
like this before, but I really wasn't so excited by the speed of generation. Now with
3delight, it's definitely feasible, updates are performed immediately. The compound
creates particles on curve list, evenly distributed, count is relative to particular
sub-curve length (still, you'll need to take care of curve re-parametrization). It's
also able to perform 'write on' on one-after-another subcurve (by sub-curve, or normalized
by sub-curve length). In short, you can 'draw' 3d strokes with it, by animating the
slider value. There are a few additional parameters. [..] contd. under si-community link
local backup: Emit Blobs From CurveList.xsicompound
local backup: Emit Blobs From CurveList.xsicompound
author site: http://www.matkovic.com / si-community thread
3Delight
v4.0.41 updated Feb 21st 2015. 3Delight is a fast, high quality, RenderMan®-compliant renderer designed to produce
photo-realistic images in demanding production environments. The renderer was introduced
to the public in the year 2000 after being used for more than a year as the sole renderer
in a sister production company. It is now widely used and earning a reputation as
a benchmark in rendering technology. [..] (cont'd on product page)
DNA research recently released the 4.0.41 upgrade along with making the free license now support up to 8-core CPUs. Highlights from the changelog: Volumetric Smoke and Shards Any shader as light source projection Exposure, Gamma Controls Mesh Light support ESC to stop render. Last year's big 4.0 update introduced features such as: support for deep EXR files Native MARI textures support Improved sampling of environment maps Added the physically plausible 3Delight Material "Continuous rendering" is now enabled by default Up to x2 acceleration in hair/fur rendering Memory usage is down 30% when using the path tracer Skin shader for 3Delight for Softimage Motion Map property is now supported
A list of movie project rendered with the 3Delight renderer. As mentioned the product is free of charge for the first 8-core license. Additional quad-core licenses are available for 400$ each and unlimited multi-core licenses for 900$ each. Yearly support and updates 190$/290$ resp.
DNA research recently released the 4.0.41 upgrade along with making the free license now support up to 8-core CPUs. Highlights from the changelog: Volumetric Smoke and Shards Any shader as light source projection Exposure, Gamma Controls Mesh Light support ESC to stop render. Last year's big 4.0 update introduced features such as: support for deep EXR files Native MARI textures support Improved sampling of environment maps Added the physically plausible 3Delight Material "Continuous rendering" is now enabled by default Up to x2 acceleration in hair/fur rendering Memory usage is down 30% when using the path tracer Skin shader for 3Delight for Softimage Motion Map property is now supported
A list of movie project rendered with the 3Delight renderer. As mentioned the product is free of charge for the first 8-core license. Additional quad-core licenses are available for 400$ each and unlimited multi-core licenses for 900$ each. Yearly support and updates 190$/290$ resp.
company page: http://www.3delight.com / product page: /en/index.php?page=3DFS_features / resource base / si-community thread (updates) / si-community thread (render tests) /
Re: 3delight tests
my english is not that good, to understand if there is anger in your second line, so sry if the *hate* was couse of something i asked.
but thanks for reply, even if I dont udnerstand the old trick yet ^^ will try it.
but thanks for reply, even if I dont udnerstand the old trick yet ^^ will try it.
Re: 3delight tests
there is no anger.sant0s wrote:my english is not that good, to understand if there is anger in your second line, so sry if the *hate* was couse of something i asked.
cheers
Re: 3delight tests
Het Mathaeus,
Funny that the issue is present in only with that specific scene, otherwise it works like charm.
Funny that the issue is present in only with that specific scene, otherwise it works like charm.
Re: 3delight tests
Well I've noticed this evening, "hitsides" isn't defined in v 3.015, again. If I remember correctly, it was defined by "both" in previous public version. Here is, in image on top, how looks like when "hitsides" is set to "both", in blocks related to point-based indirect diffuse, at the end of xsi_material.h . Especially contant shadows and hair self-shadowing. This time, all shadows are performed by point-based color bleeding, no more ray-traced AO.CiaranM wrote:Nice renders.
As for multi-bounce photons, they look great. But, I have a hard time reducing flickering in animation. I'm not sure which parameter is the key to reducing flickering (global shading rate, GI shading rate, num photons...). Any ideas?
According to behavior, I'd believe the "front" or "back" are relative to rendering (or baking ...) camera. "Both" takes a bit longer to compute, probably it requires a bit higher point-based bias.
I don't believe this could be a total solution for flicker with photons+point-based color bleeding, but without "both", it could be only worse, I think.
Re: 3delight tests
Just recently started seriously testing 3Delight and I have to say I'm really impressed and it's so easy! So much so that I may not use MR much from now on, this is great! I don't have anything really worth posting yet but just wanted to say if you haven't checked it out yet, it's worth it. The point based GI alone is worth a look but there's so much more. Big thumbs up to the guys at 3Delight and so glad we have it for SI
Re: 3delight tests
Hi,
a few more of indirect lighting, this time without photons. For two lighter pics, in baking pass I've used some mix of classic lights and spherical "light objects" (with exaggerated incandescence in material). In final render, no any classic lights, they were substituted by "light objects". Blue pic is just a zero bounce, all lighting comes from baked incandescence. Render times are about 5-10 minutes on QuadCore, using 4core 3delight.
A few observations:
Global illumination shading rate, this is used twice, as baking shading rate, also as "irradiance shading rate" in final render. So seems it's good idea to split the rendering into baking pass and final pass. For baking pass, I've used separate baking and rendering camera. Rendering camera in baking pass is pointed to "nowhere", just to avoid unnecessary render time.
To speed-up the process, I've used high-detail shading rate for baking, low-detail for final render. About 1 for baking, about 2-16 for final render. High-detail in baking, this seem to help to avoid artifacts in final render. I guess there's smaller chance for "missing" the small cylinders in point cloud. However, displacement seems to be "blurred" by irradiance shading rate (in first pic, I've painted displacement's density, irradiance shading rate is 2).
Max Solid Angle was 0.05, PTC bias 0.05.
A few about sequences... Mentioned settings seems to work fine for camera animation. For moved/deformed objects, I think a lower Max Solid Angle is a way to go, to avoid noise - at least in complex scenes. Simple scenes, just one character or so, works fine. Also I'd believe some problems I've noticed, were caused by default, view-dependent dicing in final render.
Anyway, all that PTC stuff seems to be enough fast and predictable for pleasant playing
1280x720 pic
a few more of indirect lighting, this time without photons. For two lighter pics, in baking pass I've used some mix of classic lights and spherical "light objects" (with exaggerated incandescence in material). In final render, no any classic lights, they were substituted by "light objects". Blue pic is just a zero bounce, all lighting comes from baked incandescence. Render times are about 5-10 minutes on QuadCore, using 4core 3delight.
A few observations:
Global illumination shading rate, this is used twice, as baking shading rate, also as "irradiance shading rate" in final render. So seems it's good idea to split the rendering into baking pass and final pass. For baking pass, I've used separate baking and rendering camera. Rendering camera in baking pass is pointed to "nowhere", just to avoid unnecessary render time.
To speed-up the process, I've used high-detail shading rate for baking, low-detail for final render. About 1 for baking, about 2-16 for final render. High-detail in baking, this seem to help to avoid artifacts in final render. I guess there's smaller chance for "missing" the small cylinders in point cloud. However, displacement seems to be "blurred" by irradiance shading rate (in first pic, I've painted displacement's density, irradiance shading rate is 2).
Max Solid Angle was 0.05, PTC bias 0.05.
A few about sequences... Mentioned settings seems to work fine for camera animation. For moved/deformed objects, I think a lower Max Solid Angle is a way to go, to avoid noise - at least in complex scenes. Simple scenes, just one character or so, works fine. Also I'd believe some problems I've noticed, were caused by default, view-dependent dicing in final render.
Anyway, all that PTC stuff seems to be enough fast and predictable for pleasant playing
1280x720 pic
Last edited by Mathaeus on 02 Nov 2011, 10:02, edited 1 time in total.
Re: 3delight tests
big thanks to your tests. your last ones looks really good.
i wish i had some time at the moment to play more with 3delight.
i wish i had some time at the moment to play more with 3delight.
Re: 3delight tests
Mathaeus,
nice, and thanks for posting your details. Im still a little confused with the baking and rendering side and your posts are helping. I'm currently trying out the demo of 3Delight and impressed with the speed of it all (and the amazing Softimage integration of the shaders!) even though 2 cores are used. Ive been playing around with the SSS parameters but still rendering tests, will try and post something when its finished rendering
Essentially I want to find out about brick maps. and find a way to make / bake a low res lighting SSS geometry spheres into a high res fractally displaced geometry. a cloudy kind of thing Have tried using SSS on the displaced geometry and it is too prohibitave, so am exploring the brick map / ptc route.
anyways , keep the tests coming
cheers
nice, and thanks for posting your details. Im still a little confused with the baking and rendering side and your posts are helping. I'm currently trying out the demo of 3Delight and impressed with the speed of it all (and the amazing Softimage integration of the shaders!) even though 2 cores are used. Ive been playing around with the SSS parameters but still rendering tests, will try and post something when its finished rendering
Essentially I want to find out about brick maps. and find a way to make / bake a low res lighting SSS geometry spheres into a high res fractally displaced geometry. a cloudy kind of thing Have tried using SSS on the displaced geometry and it is too prohibitave, so am exploring the brick map / ptc route.
anyways , keep the tests coming
cheers
Gossip is what no one claims to like, but everybody enjoys.
Re: 3delight tests
afaik, brick-maps aren't featured in 3dfs plugin. However, subsurface scattering is baked into point cloud (at least with ptc based color-bleeding). So, if you're using "hitsides" "both", it seems there is a really dirty trick: use displacement and subsurface in baking pass. In final render, disable subsurface and apply a slightly negative Push SI operator, use only radiance in some standard SI shader (that is, diffuse to black, disable 'filter radiance with diffuse'). Now surface takes a 'self' radiance.
Of course, this is a really dirty trick, I have no idea what problems this could do on more than my simple test....
Btw, if you didn't already, you can install a 'big' 3delight and preview the ptc files with ptcview - ptcview works with free license too.
Of course, this is a really dirty trick, I have no idea what problems this could do on more than my simple test....
Btw, if you didn't already, you can install a 'big' 3delight and preview the ptc files with ptcview - ptcview works with free license too.
Re: 3delight tests
heres that render test I promised, was rendered over a few days with the free 2 core vorsion. really like the 3delight stability and consistency in SSS. no flickering or crashing ! definately going to try some things out with rendering pointclouds. Anto, I really like the idea of 'baking' shadows and sss data in before rendering but unfortunately in this instance it would not make much difference as the particle objects are changing in size & position every frame.
Gossip is what no one claims to like, but everybody enjoys.
Re: 3delight tests
Really nice to see how 3dl subsurface "melts" all that overlapping volumes. Something that only renderer can do ...Tekano wrote:heres that render test I promised, was rendered over a few days with the free 2 core vorsion. really like the 3delight stability and consistency in SSS. no flickering or crashing ! definately going to try some things out with rendering pointclouds.
Re: 3delight tests
A few in Christmas style , using 3dfs 3.1.0
First two are variances of point-based color bleeding. First is one standard light, pointed from back to camera, together with color bleeding. Second is solely point-based IBL. Render for each image took about 25 minutes on Quad Core machine, using 4core 3delight, for 50K hairs and the rest of geometry. I did only basic optimization, like very high GI shading rate for hairs, about 64. Point-based bias is about 0.02. Baking is performed in separate pass, with shading rate 2 for all. Didn't tried additional trickery for speed-up, like using GI falloff, low-res hair geometry for hairs, higher point-based bias.
Generally all this was possible before, but this time everything is done with out-of-the-box stuff. No hacking of sl files.
Third is just a pair of classic lighs on 100k hairs, together with a new, polygonal aperture DOF. This one took about 4 minutes to render.
First two are variances of point-based color bleeding. First is one standard light, pointed from back to camera, together with color bleeding. Second is solely point-based IBL. Render for each image took about 25 minutes on Quad Core machine, using 4core 3delight, for 50K hairs and the rest of geometry. I did only basic optimization, like very high GI shading rate for hairs, about 64. Point-based bias is about 0.02. Baking is performed in separate pass, with shading rate 2 for all. Didn't tried additional trickery for speed-up, like using GI falloff, low-res hair geometry for hairs, higher point-based bias.
Generally all this was possible before, but this time everything is done with out-of-the-box stuff. No hacking of sl files.
Third is just a pair of classic lighs on 100k hairs, together with a new, polygonal aperture DOF. This one took about 4 minutes to render.
Re: 3delight tests
the third looks the best, alot because of the direct lights with shadows i think. spec is also great which i miss in the ibl rendering alot. diffuse illum of the ibl is best i think, like the gi look of it. scattering effect is low, it needs some additionel lights here. rendertime is good for all images for 4 threads only.
Re: 3delight tests
Hi,
this one is about 3delight "hit mode" property, when is set to ‘Use SurfaceColor3Delight Vertex Property’. In this "hit mode", if object has a CAV property with this name, ray-traced GI takes a vertex color, instead of shader evaluation. Name should be exactly SurfaceColor3Delight, it's case sensitive. Ray-traced GI renders at speed similar to ray-traced AO, still with ability to catch the color of another object. To get the desired render time, all involved objects should carry the mentioned property.
This is how it looks like with "light objects". Light object has a bright vertex color, the rest is plain black. Render time on Quad Core, 4 core 3delight, is about 3-9 minutes - this one took about 9 min. I've set GI shading rate enough sharp to catch the displacement.Something about GI shading rate 0.5, 256 samples.
Now a bit of hacking. It seems, 'hit mode' applies fine to "gather" function, used for glossy reflections. So, by adding a few lines to mia_material.sl , like:
we will get something like this pic, using glossy reflection from MIA material. Now, with even sharper shading rate, about 0.15, render time is about 4 min.
Of course this is just one-level reflection, for more than this, "next ray" should be baked into CAV, somehow. Probably with some fancy ICE solution. Anyway, I think the render time makes it really interesting.
this one is about 3delight "hit mode" property, when is set to ‘Use SurfaceColor3Delight Vertex Property’. In this "hit mode", if object has a CAV property with this name, ray-traced GI takes a vertex color, instead of shader evaluation. Name should be exactly SurfaceColor3Delight, it's case sensitive. Ray-traced GI renders at speed similar to ray-traced AO, still with ability to catch the color of another object. To get the desired render time, all involved objects should carry the mentioned property.
This is how it looks like with "light objects". Light object has a bright vertex color, the rest is plain black. Render time on Quad Core, 4 core 3delight, is about 3-9 minutes - this one took about 9 min. I've set GI shading rate enough sharp to catch the displacement.Something about GI shading rate 0.5, 256 samples.
Now a bit of hacking. It seems, 'hit mode' applies fine to "gather" function, used for glossy reflections. So, by adding a few lines to mia_material.sl , like:
we will get something like this pic, using glossy reflection from MIA material. Now, with even sharper shading rate, about 0.15, render time is about 4 min.
Of course this is just one-level reflection, for more than this, "next ray" should be baked into CAV, somehow. Probably with some fancy ICE solution. Anyway, I think the render time makes it really interesting.
Re: 3delight tests
Hey Matheus, very nice!
Looking at your test, and from my (very little) experience messing with 3delight, I wonder why guys at DNAResearch dont make theyre own sahders, at least one for regular stuff and other for SSS. The way things are arranged right now I feel like one has to think in a REYES way but with raytracer tools, which feels akward. Not to mension it converts MIA perfectly, in its good and bad aspects...
As you showed us, with the appropriate shaders one can levarage the best of this renderer.
Looking at your test, and from my (very little) experience messing with 3delight, I wonder why guys at DNAResearch dont make theyre own sahders, at least one for regular stuff and other for SSS. The way things are arranged right now I feel like one has to think in a REYES way but with raytracer tools, which feels akward. Not to mension it converts MIA perfectly, in its good and bad aspects...
As you showed us, with the appropriate shaders one can levarage the best of this renderer.
Gustavo Eggert Boehs
Blog: http://www.gustavoeb.com.br/
Blog: http://www.gustavoeb.com.br/
Re: 3delight tests
Actually 3delight team lead mentioned this, somewhere on 3dl forums. Of course I have no idea when this will happen. This is mentioned before one year or so. Who knows, maybe sooner than later.gustavoeb wrote:Hey Matheus, very nice!
Looking at your test, and from my (very little) experience messing with 3delight, I wonder why guys at DNAResearch dont make theyre own sahders, at least one for regular stuff and other for SSS.
Imho yes, subsurface especially makes confusion, being crippled by "cheaper" shading model, still without all mi_sss specific parameters.
Who is online
Users browsing this forum: No registered users and 12 guests