 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I see. So the interior statement is misleading incase of triangles since it
> is no interior. It is like a switch to turn on interior calculation if it
> hits the triangle until it hit an other object, rather than an interior of
> the triangle (which one would think if entering the POV statement).
The triangle has no thickness. It has no interior. To have done it "right"
we would have disabled interior for triangles, but the way it is gives more
flexibility in cases like yours.
> Just one further question:
> If I store millions of triangles in a mesh it is not a big problem since
> meshes store triangles efficiently and build a hierarchical octree of the
> structure. This speeds up tracing.
> Will I lose this if I switch to a union of triangles? (since interior
> doesn't work on triangles in meshes). Will tracing speed decrease and memory
> usage increase??
Yes, you will lose this. You can compensate, a little, by breaking the big
union up into smaller unions and bounding them separately.
In addition, if you specify different interiors for different triangles, you
will have other problems. One of the other problems you will have is that
this:
union {
triangle {x,y,x+y interior {...whatever...}}
triangle {x+z,y+z,1 interior {...whatever...}}
}
won't get rendered the way you expect it to, because the two interiors
there are utterly independent of each other. This:
union {
triangle {x,y,x+y}
triangle {x+z,y+z,1}
interior {...whatever...}
}
will be closer to what you want.
In addition, it's still possible for a ray to sneak between the two triangles
and give you funny borders around your triangle. That might be the cause of
the black lines you mentioned before.
--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Meshes silently drop degenerate triangles. Keep in mind that there's more
>> ways for a triangle - especially a smooth triangle - to be degenerate than
>> just the obvious "collinear vertices" one.
>
> Like?
If the normal vectors aren't all within 90 degrees of each other.
> begin 666 media.jpg
Please put binaries in the proper place.
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > doesn't work on triangles in meshes). Will tracing speed decrease and
memory
> > usage increase??
>
> Yes, you will lose this. You can compensate, a little, by breaking the
big
> union up into smaller unions and bounding them separately.
*lol* this is the point where I started from. Then I made it a single mesh
to speed it up (I had 30000 objects which made bounding test very slow). Now
I will have to flip back again ....
> In addition, if you specify different interiors for different triangles,
you
> will have other problems. One of the other problems you will have is that
> this:
>
> union {
> triangle {x,y,x+y interior {...whatever...}}
> triangle {x+z,y+z,1 interior {...whatever...}}
> }
>
> won't get rendered the way you expect it to, because the two interiors
> there are utterly independent of each other. This:
Yes I am aware of this. But since the interior has no structure (just a
foggy -something-) this wouldn't be a problem.
> union {
> triangle {x,y,x+y}
> triangle {x+z,y+z,1}
> interior {...whatever...}
> }
>
> will be closer to what you want.
Yep. And this would be also necessary for bounding reasons.
> In addition, it's still possible for a ray to sneak between the two
triangles
> and give you funny borders around your triangle. That might be the cause
of
> the black lines you mentioned before.
The current thing doesn't use interior at all. The borders seem to be a
"numeric resolution" problem. It is alwys a single pixel regardless of the
rendering resolution.
regards
SY
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If the normal vectors aren't all within 90 degrees of each other.
Hm. I once created such a smooth_triangle manually. It rendered weird, of
course, but ther was no message about a degenerate triangle. (?)
> > begin 666 media.jpg
>
> Please put binaries in the proper place.
I wanted to have the pic in the text context.
regards
SY
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Please put binaries in the proper place.
>
> I wanted to have the pic in the text context.
Our rules on this news server are pretty simple - binaries in binaries groups
and text in text groups. Please respect our wishes in this regard.
--
Ken Tyler - News Admin.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c7b48c6$1@news.povray.org>,
> > real world remotely like this. The closest thing would be an ior
> > variable over space, which POV is incapable of doing (and which would
>
> I don't care about IOR. I just want a thing like thick fog. However, same
> problem of course.
Then why are you trying to apply different interiors to individual
triangles? Just use a density pattern. POV is capable of rendering a
varying density media...it doesn't change the ray direction, so it
requires much less computing power.
Maybe you should give a better description of what you are trying to do.
--
Christopher James Huff <chr### [at] mac com>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> If the normal vectors aren't all within 90 degrees of each other.
>
> Hm. I once created such a smooth_triangle manually. It rendered weird, of
> course, but ther was no message about a degenerate triangle. (?)
This might be new in 3.5.
--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I wanted to have the pic in the text context.
>
> Our rules on this news server are pretty simple - binaries in binaries
groups
> and text in text groups. Please respect our wishes in this regard.
Sure I'll respect.
But it is pretty unhandy. Why don't it make user friendly?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Then why are you trying to apply different interiors to individual
> triangles? Just use a density pattern. POV is capable of rendering a
Uhm. Up to now I thought the density thing is related to media which is
related to interiors. That's what I understood by reading the help doc. I
will go over it again to follow your hint.
Thanks.
> Maybe you should give a better description of what you are trying to do.
Just follow up the thread. I gave a clear description.
The problem is i am looking for a good method to simulate this "foggy milk
glass effect" without adding too much complexity. Maybe it is not possible
but as long there are specialists I can ask them, right?
I don't have a specific problem like artefacts or error messages or
whatever. I'm just looking for solutions.
Thanks and regards,
SY
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<sch### [at] surfeuat> wrote:
> Sure I'll respect.
> But it is pretty unhandy. Why don't it make user friendly?
Because not everybody has a high-speed internet connection: When going
through groups and having to download megabytes of useless images, it is very
annoying and takes very long to read because one obviously has to wait for the
download. So keeping some order is actually friendly and involves less
waiting for everybody.
For practical purposed you should always say in which binary group you put the
image and in the image description you simply say which thread in which group
you are referring to. This is sufficient for someone interested to find both,
and for those not interested in the image to not have to download it.
BTW, for a summary of all rules lots of other useful information, you may want
to read povray.announce.frequently-asked-questions in case you haven't yet.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
