 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge schrieb:
>> Have you /actually/ gotten that to work?
>
> Oh crap, /I/ just got it to work! When did this start being possible??
> Oh cool :)
Phew - I just was about to confess that no, I never actually tested it
with the inside() function ;-)
(But I'd have been surprised if the SDL inside() function would used any
other mechanism than the very same inside test that's used in CSG, which
I knew works fine with inside_vector.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> stbenge schrieb:
> >> Have you /actually/ gotten that to work?
> >
> > Oh crap, /I/ just got it to work! When did this start being possible??
> > Oh cool :)
>
> Phew - I just was about to confess that no, I never actually tested it
> with the inside() function ;-)
>
> (But I'd have been surprised if the SDL inside() function would used any
> other mechanism than the very same inside test that's used in CSG, which
> I knew works fine with inside_vector.)
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...
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote:
> clipka wrote:
>
>> stbenge schrieb:
>>
>>> And of course you can never use this with meshes. That is, not until
>>> somebody figures out how to convince POV into turning a mesh into a
>>> bona-fide object pattern...
>>
>>
>> You mean, like adding an "inside_vector" statement to the mesh? :-P
>
>
> Have you /actually/ gotten that to work?
http://tinyurl.com/kvww3t
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Reactor <rea### [at] hotmailcom> wrote:
> 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...
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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
From: stbenge
Subject: Re: edge_pigment02.inc (a proximity pattern)
Date: 24 Aug 2009 17:15:22
Message: <4a9302ea@news.povray.org>
|
|
|
| |
| |
|
|
Jim Charter wrote:
> stbenge wrote:
>> clipka wrote:
>>> You mean, like adding an "inside_vector" statement to the mesh? :-P
>>
>> Have you /actually/ gotten that to work?
>
> http://tinyurl.com/kvww3t
Awesome image! I'm guessing that beautiful chalice is a mesh?
I have tried making meshes into object patterns in the past, but without
success. Even after defining an inside_vector, I received errors.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote:
> Jim Charter wrote:
>
>> stbenge wrote:
>>
>>> clipka wrote:
>>>
>>>> You mean, like adding an "inside_vector" statement to the mesh? :-P
>>>
>>>
>>> Have you /actually/ gotten that to work?
>>
>>
>> http://tinyurl.com/kvww3t
>
>
> Awesome image! I'm guessing that beautiful chalice is a mesh?
>
> I have tried making meshes into object patterns in the past, but without
> success. Even after defining an inside_vector, I received errors.
I don't remember anymore, it's so long ago. I do remember that I got the
idea from you, when you rounded the corners off a cube by jittering it
inside a intersection block, I believe.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
