 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
For comparison, a version without subsurface scattering.
Post a reply to this message
Attachments:
Download 'ssltdie_.png' (120 KB)
Preview of image 'ssltdie_.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> How about this one?
Perfect!
The with/without comparison is very interesting as well.
Regards,
Dave Blandston
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/22/2011 08:40 PM, clipka wrote:
> The die is actually an isosurface I had modelled earlier for a different
> scene; DON'T TRY THIS AT HOME WITH SSLT! Kudos to Kevin Loney, Jaap
> Frank & Tor Olav Kristensen for their isosurface approximator include
> file, which cut down the rendering time by a guesstimated 98-99% (!) to
> "only" 3.5 hours.
no kidding ... why is that with isosurfaces the render times skyrocket
(besides the obvious isosurface slow downs) ... i tried to make coral
material for my mandel goodie and after overnight on 13% progress ...my
guess is that up until now that fairly simple objects have been used as
demo. you guys are getting fairly decent times with mesh objects am i
correct? iso's are just a more complicated surface to consider
(sslt-wise) is that the reason? btw: did that test with RC3 bits ...
should i expect similar performance with updated method?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback <jho### [at] povrayorg> wrote:
> you guys are getting fairly decent times with mesh objects am i
> correct? iso's are just a more complicated surface to consider
> (sslt-wise) is that the reason?
Yes, meshes typically render very quickly. Isosurfaces are always going to be
slow, there's so much math going on in there... and with transparency or SSLT,
yikes, that could be a real rendering-time nightmare.
-------------------------------------------------
www.McGregorFineArt.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/02/2011 6:21 PM, Robert McGregor wrote:
> Yes, meshes typically render very quickly.
I second that.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.02.2011 13:11, schrieb Jim Holsenback:
> no kidding ... why is that with isosurfaces the render times skyrocket
> (besides the obvious isosurface slow downs) ...
Actually it /is/ the obvious isosurface slow downs. SSLT is very
intersection-test-intensive, and that's exactly where isosurfaces suck.
> should i expect similar performance with updated method?
Yup. Updated stuff includes bugfixes & an easier-to-use syntax, but no
performance improvements yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Yup. Updated stuff includes bugfixes & an easier-to-use syntax, but no
> performance improvements yet.
I've noticed a weird X-pattern on superellipsoid faces with SSLT in RC3, just
wondering if you get the same thing with the new method.
Here's an image that illustrates what I mean - the left superellipsoid has the
X-pattern (like triangular faces with non-planar normals), the right
superellipsoid is the exact same but with no SSLT and using reflection &
transmit instead, but it looks as expected.
So, how does your die scene look using a superellipsoid instead of the
isosurface approximation mesh?
-------------------------------------------------
www.McGregorFineArt.com
Post a reply to this message
Attachments:
Download 'sslt_embossed_superellipsoid.png' (217 KB)
Preview of image 'sslt_embossed_superellipsoid.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> I've noticed a weird X-pattern on superellipsoid faces with SSLT in RC3, just
> wondering if you get the same thing with the new method.
>
> Here's an image that illustrates what I mean - the left superellipsoid has the
> X-pattern (like triangular faces with non-planar normals), the right
> superellipsoid is the exact same but with no SSLT and using reflection &
> transmit instead, but it looks as expected.
For comparison here's an SSLT box using the same basic setup - no X-pattern in
the box though, just in the superellipsoid...
-------------------------------------------------
www.McGregorFineArt.com
Post a reply to this message
Attachments:
Download 'sslt_box.png' (284 KB)
Preview of image 'sslt_box.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.02.2011 23:14, schrieb Robert McGregor:
> I've noticed a weird X-pattern on superellipsoid faces with SSLT in RC3, just
> wondering if you get the same thing with the new method.
>
> Here's an image that illustrates what I mean - the left superellipsoid has the
> X-pattern (like triangular faces with non-planar normals), the right
> superellipsoid is the exact same but with no SSLT and using reflection&
> transmit instead, but it looks as expected.
Did you use radiosity for those images? If so, can you try again without
radiosity?
If it appears only when radiosity is enabled, chances are it will be
fixed with the next release.
Otherwise there might be some distance threshold hidden in the
superellipsoid intersection testing code; SSLT is quite sensitive to
such things, as it needs to shoot rays from just slightly below the
surface. I know that blobs have such issues, for instance. To really fix
that, I'd need to do some changes deep in the bowels of POV-Ray - which
of course is a no-go during release candidate phase.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.02.2011 23:14, schrieb Robert McGregor:
> So, how does your die scene look using a superellipsoid instead of the
> isosurface approximation mesh?
No such artifacts here, so I'm optimistic that it's something I fixed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
