 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Reactor schrieb:
> Which kind of makes me wonder why inside_vector doesn't have a default value.
> It seems like the direction rarely matters that much, but if you forget to
> specify it...
Backward compat I suppose: Until the introduction of inside_vector, I
assume intersecting a mesh with a solid would give you the same result
as clipping the mesh by that object, and some scenes might have relied
on this effect; defaulting to a proper inside_vector would obviously
break such scenes.
Then again, I guess it would be not much of a problem to default to
inside_vector y (for instance) unless a #version statement is used to
request compat with 3.6 or lower. And a warning could be given even
then, suggesting to use clipped_by instead.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
> My guess is that specifying inside_vector makes the rendering of the
> mesh slower in some situations (probably eg. when there's media or fog
> around), which is why it's turned off by default.
I don't think so. Media would only be computed inside a mesh if the
"hollow" keyword is also used anyway.
The only place where it should make a difference is when used with CSG
intersection: In that case, performing proper inside tests instead of
just returning "not inside" would be faster of course.
Anyway, the speed issue could be mitigated by allowing to explicitly
specify "inside_vector <0,0,0>" (or, being equivalent yet more talktive,
"inside_vector no") to disable inside tests.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Warp schrieb:
> > My guess is that specifying inside_vector makes the rendering of the
> > mesh slower in some situations (probably eg. when there's media or fog
> > around), which is why it's turned off by default.
> I don't think so. Media would only be computed inside a mesh if the
> "hollow" keyword is also used anyway.
Except that meshes have no inside and thus no insideness is computed for
them. (Except if inside_vector is specified, of course.)
> Anyway, the speed issue could be mitigated by allowing to explicitly
> specify "inside_vector <0,0,0>" (or, being equivalent yet more talktive,
> "inside_vector no") to disable inside tests.
That might break existing scenes, especially those which use *open* meshes
and assume that meshes have no inside.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
>>> My guess is that specifying inside_vector makes the rendering of the
>>> mesh slower in some situations (probably eg. when there's media or fog
>>> around), which is why it's turned off by default.
>
>> I don't think so. Media would only be computed inside a mesh if the
>> "hollow" keyword is also used anyway.
>
> Except that meshes have no inside and thus no insideness is computed for
> them. (Except if inside_vector is specified, of course.)
... which is exactly the difference we're discussing here: Whether
having meshes to default to a valid inside_vector would make a difference.
>> Anyway, the speed issue could be mitigated by allowing to explicitly
>> specify "inside_vector <0,0,0>" (or, being equivalent yet more talktive,
>> "inside_vector no") to disable inside tests.
>
> That might break existing scenes, especially those which use *open* meshes
> and assume that meshes have no inside.
That's what I already mentioned in the first place, and commented on
possible solutions, in case you didn't notice. Here I just focused on
the speed issues.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
