 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I reckon I can't be the first person to notice this, so hopefully someone can
help.
This is a mesh2 object using smooth triangles (created by PoseRay), but it has a
wierd black artefact. I think all polygons that have one of their corner's
normals pointing away from the camera are being drawn black. Has anyone else had
this problem? Is there any way to fix it?
Thanks,
--
Tek
http://www.evilsuperbrain.com
Post a reply to this message
Attachments:
Download 'Hop_thunderhawk_test.jpg' (14 KB)
Preview of image 'Hop_thunderhawk_test.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It's in the FAQ in the povray docs. Slime-POV fixes it.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's in the FAQ in the povray docs. Slime-POV fixes it.
Oh, I should mention that the "double_illuminate" keyword will also
workaround this, provided you don't need to see the mesh from the inside.
(What's actually happening is that it thinks parts of the triangles are on
the inside when they're on the outside, and vice versa.)
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <slm### [at] slimeland com> wrote in message news:3e2a20be$1@news.povray.org...
> > It's in the FAQ in the povray docs. Slime-POV fixes it.
>
>
> Oh, I should mention that the "double_illuminate" keyword will also
> workaround this, provided you don't need to see the mesh from the inside.
> (What's actually happening is that it thinks parts of the triangles are on
> the inside when they're on the outside, and vice versa.)
double_illuminate works okay so long as I turn off radiosity, but I'll try
Slime-pov. Plus you've fixed the shadow-line artefact, if you look at the planet
image I posted the other day you can see it suffers from it! (though I can get
round that using no_shadow).
Sounds like you've been fixing lots of glitches that have been causing me
trouble! :)
--
Tek
http://www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Keep in mind, Slime-POV has one or two of its *own* bugs, I think... =)
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Slime" <slm### [at] slimelandcom> wrote in message
news:3e2acb0b$1@news.povray.org...
Wait. You "fixed" the shadow line problem?! If so, this is very exciting.
By shadow line problem, are we talking about the hard shadow between
illuminated smooth triangles and non-illuminated? If so, I can remove
several hundred triangles from some of my models.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Wait. You "fixed" the shadow line problem?! If so, this is very exciting.
>
> By shadow line problem, are we talking about the hard shadow between
> illuminated smooth triangles and non-illuminated? If so, I can remove
> several hundred triangles from some of my models.
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.
See http://www.slimeland.com/slimepov/docs.html#section15 for more info.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
