"Slime" <slm### [at] slimelandcom> wrote in message
news:3e2c83ff$1@news.povray.org...
>
> Yes. It's an ugly hack, but it works in most cases. Not all. It's not
> implemented in MegaPOV, and I don't ever expect it to be, because it goes
> *all* over the lighting code, variables going every which way, and it's
ugly
> and spaghetti coded. It basically uses the algorithm that's in the FAQ
near
> the end of the POV-Ray documentation.

Excellent. I will be downloading Slime-Pov tonight.

I have a suggestion for what might be a very nice feature, although I'm not
sure if it's feasible. Would there be a way to modify your optimal quad
division code to work on all meshes containing quads and to calculate the
split during the render instead of at parse time?

The idea would be for PoV-Ray to store one quad instead of two triangles in
memory. The render would of course be slower, but some memory could be saved
for meshes containing mostly quads. This might be enough to really improve
the capabilities of things like grass macros.

This idea could even be expanded beyond quads to include cylinder, torus,
box, cone, etc. type constructs. This would allow for greebling the likes of
which home computer using gui types could only dream. I doubt anyone would
use it, however.

Just a thought.

 -Shay

Post a reply to this message