Problem....need some help

[Dave Black]

I don't use brazil, but I am utterly in-love with shag:hair, and I feel your pain. I've run into similar problems with integrating shag with other rending systems.

Perhaps the fine users of this board will know of a more definate work-around, but the only thing I could offer is possibly rendering out the hair in a seperate pass, and the comping into the scene in post.

Just a thought. I hope there is an easier way...

-3DZ

:D

[S_3D_A]

Interesting. Hey thanks alot Zeal I've been cranking my head on how to get around this and never thought about heading in that direction. Will give this a shot.

[ZeBoxx]

Heya,

The problem I run into is that Brazil atm is not compliant with Shag.

I didn't know Brazil r/s had to be 'compliant' with Shag ;)
But if you mean compatible - it sure enough is.

I'm running 1.0.14 (the latest client release) - I take it since you bought Shag that you bought Brazil r/s as well, so I'd very much recommend updating; might've been an old bug in 1.0

Regardless, I'm not saying there aren't known issues.

For example - two common ones (and they're not exclusive to Brazil r/s)

1) Shag doesn't receive skylight/GI
That is correct - although 3ds max provides a few basic accessors through the SDK/APIs to get at lighting information, this lighting information is mostly restricted to basic light types.
Skylight and GI aren't basic light types - they aren't even "nodes" for 3ds max to interrogate.
In other words - for Shag to get skylight or GI lighting it, it first has to be made aware of these systems, or implement a Skylight/GI system internally.
A good example is Sitni Sati's Dreamscape - it has its own Daylight system.

2) Shag is taking forever, it keeps re-calculating things
That is also correct. Shag is more or less a post-effect/atmospheric hybrid. It prerenders the Shag fur/hair to a buffer of a certain height when you render (simplified).
So if you have a 640x480 render, and you have a buffer height of <edit>120</edit>, the image would hold 4 virtual buffers.
With the Scanline renderer, the order is always that of scanlines going from top to bottom.
So it would first render Buffer A, then Buffer B, then Buffer C and then Buffer D.

Now watch what happens when you throw a bucket renderer at it with a different ordering than Top > Bottom. For example - spiraling out.
It would first render Buffer B, then Buffer C, then Buffer B again, then Buffer C again, then Buffer B again, then Buffer A, then Buffer B again, then Buffer C again, then Buffer D, then Buffer C again, then Buffer B again, then Buffer A again, then Buffer B again, then Buffer C again, then Buffer D again, then Buffer C again then Buffer B again, then Buffer A again and finally Buffer D again.

Whew. Yeah, I suppose that -would- be slow huh ? :)
And that's with buckets that border the buffer zones precisely. Imagine a bucket overlapping two buffer zones ;)

That's not to blame on the rendering system, or even Shag - that's just how things work.
So if you use Shag, be sure to either
A) Render Top > Bottom using whatever renderer you use.
B) Set Shag's buffer height equal to the image's height (this will take more RAM)

Welp, hope that helps to at least clear up some common misunderstandings.

Best regards,
Richard Annema

<edit>heh.. 120, not 160 ;)</edit>

[Dave Black]

Told ya someone would be "in-the-know". :D

Thanks for taking all that time to write a beautiful explination on how this all works, ZeBoxx. I ,personally, really apprecieate it.

I think that addresses the initial problem...

Thanks again, ZeBoxx, and S_3D_A, I hope it all works out for ya.

-3DZ

:D

[S_3D_A]

Thanks a bunch for the reply Zeb everything seems to be kosher now since update:)

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.