The promise of having a shorter render time by using my fast proximity 
pattern macros was, in a sense, a sham. They might render faster, but 
the parsing is... painfully slow.

Here is a pattern that will parse more quickly. It might be a little 
slower to render, but consider the trade-off: by increasing the render 
time a small amount you can save time parsing. But more importantly you 
gain a level of detail you can only achieve with object patterns.

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...

Sam

Post a reply to this message

Attachments:
Download 'edge_pigment02.inc.txt' (9 KB)

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

Post a reply to this message

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?

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?

Oh crap, /I/ just got it to work! When did this start being possible?? 
Oh cool :)

Post a reply to this message

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] anonymousorg> 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

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