 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have an arc that I made by differencing from a cylinder a slightly
thicker cylinder with smaller radius, a cube, and another cube.
Would making a CSG merge of the differenced cylinders with a box
be quicker?
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 13 Feb 2002 21:45:25 -0500, "Timothy R. Cook"
<tim### [at] scifi-fantasy com> wrote:
>I have an arc that I made by differencing from a cylinder a slightly
>thicker cylinder with smaller radius, a cube, and another cube.
>Would making a CSG merge of the differenced cylinders with a box
>be quicker?
Two ways to test: Either make both constructions and check the
end-render stats for each, or check how close the vista-buffers hug
the object.
/Erkki
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Two ways to test: Either make both constructions and check the
> end-render stats for each, or check how close the vista-buffers hug
> the object.
It's more of a general question, as I have a large number of instances
wherein if discreet CSGs are faster, then the whole scene will be
sped up, but if they're not, I don't want to spend the time changing
everything just to check, then find out it's not...
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 14 Feb 2002 05:53:36 -0500, "Timothy R. Cook"
<tim### [at] scifi-fantasycom> wrote:
>> Two ways to test: Either make both constructions and check the
>> end-render stats for each, or check how close the vista-buffers hug
>> the object.
>
>It's more of a general question, as I have a large number of instances
>wherein if discreet CSGs are faster, then the whole scene will be
>sped up, but if they're not, I don't want to spend the time changing
>everything just to check, then find out it's not...
I suggested that you test for yourself because it's been a long time
since I was current enough on the POV-Ray internals to answer the
question off the top of my head.
Difference is a tricky construction to autobound tightly, there's that
nasty INVERSE keyword involved. In general a difference can't be
bounded internally at lower levels than the whole object, if a ray
hits the 'outer' object all 'inner' objects will have to be evaluated.
As the number of 'inner' objects increase the total evaluation cost
increases as well.
Look at your end-render statistics and look closely at the hit-rates.
If your hit-rate is below 10% or so you have a problem, if it's below
1% you have a big problem!!
In general differences with less than 5 inner objects shouldn't cause
problems, below 10 objects you shouldn't have big problems, but this
is just my ROT. YMMV.
/Erkki
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's more of a general question, as I have a large number of instances
> wherein if discreet CSGs are faster, then the whole scene will be
> sped up,
If you're referring to your Orca image, I can say there's definitely
something wrong with the render-time.. I don't use Moray however so I don't
know how much control it provides you with CSG.. But I can say, in general
you should stay away from "merge" and use "union" instead.. Merge is only
for transparant objects and much slower, in most cases.. You should also
avoid "difference" "intersection" when you can get away with pure
primitives.. OR, if Moray can transform your CSG shapes into meshes, you
should perhaps consider this because meshes are fast.
This makes a BIG difference. Personally I always stick to this rule, that
serves me well: I can use lots of pure primitives (several thousands is no
problem, they render fast!), and lots of mesh data, but NOT much of
"difference", "merge" and "intersection"..
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hugo wrote:
> But I can say, in general you should stay away from "merge" and
> use "union" instead.
It seems to me I read somewhere that merges were faster...?!
Hmm too bad you can't put groups inside of CSGs, or I could
do away with a lot of the CSGs I have...
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
By the way... You mentioned that you "nest" the CSG... Well, maybe this is
not what you meant, BUT ... if you mean that for example you nest all
objects inside a "difference" statement, you have a problem! I'm quite sure
Povray will then calculate ALL the objects you've nested, for ALL pixels (so
to say..) on screen ..... and this will give a crazy render time.. Normally,
objects are only calculated at the place on the screen where they appear,
and this is a major speed-up.. Objects should only be nested when
*necessary* ... or you can put them safely in a "union" because this doesn't
have a negative impact on the speed.
Hope I made myself clear ... english is not my native language, but this is
important for you to know ... if you don't know it already.
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > But I can say, in general you should stay away from "merge" and
> > use "union" instead.
>
> It seems to me I read somewhere that merges were faster...?!
In SOME cases, merge is faster, but be careful with this.. I've never
experienced a case yet where merge wasn't 2 times slower in my scene.
> Hmm too bad you can't put groups inside of CSGs, or I could
> do away with a lot of the CSGs I have...
Sorry I'm not sure what you mean by that.. But I just posted an additional
comment about grouping objects - group them only with "union"...! :o)
Regards
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C6C4F59.4E398A13@scifi-fantasy.com>,
"Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote:
> It seems to me I read somewhere that merges were faster...?!
If the object is transparent, using a merge will avoid the texture and
shadow computations for all the internal surfaces, and so can be faster
than a simple union. Normally, a union is faster though.
> Hmm too bad you can't put groups inside of CSGs, or I could
> do away with a lot of the CSGs I have...
How does a union not work for this?
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hugo wrote:
> By the way... You mentioned that you "nest" the CSG... Well, maybe this is
> not what you meant, BUT ... if you mean that for example you nest all
> objects inside a "difference" statement, you have a problem!
...
Um...
*whistles innocently*
Here's the CSG nesting of ONE of the levels:
LevelB (merge)
Beta_Solid (merge)
Beta_Hull (difference)
Beta_Hull1 (intersection)
Beta_Hull1T (sphere)
Beta_Hull1M (cylinder)
Beta_Hull1B (sphere)
Beta_Hull0 (intersection)
Beta_Hull0T (sphere)
Beta_Hull0M (cylinder)
Beta_Hull0B (sphere)
Beta_Tube_Hole (intersection)
Beta_Tube_Round (cylinder)
Beta_Tube_Box (cube)
CSG010 (difference)
Cylindr006 (cylinder)
Cylindr007 (cylinder)
Beta_Floors (merge)
Beta_Floor_L00 (cylinder)
Beta_Floor_L01 (cylinder)
Beta_Floor_L02 (cylinder)
Beta_Floor_L03 (cylinder)
Beta_Floor_L04 (cylinder)
Beta_Floor_L05 (cylinder)
Gamma_Solid (merge)
SAME AS BETA
Delta_Solid (merge)
SAME AS BETA
Labs_Solid (merge)
SAME AS BETA
And there's 2 copies of LevelB as LevelC and LevelD,
then there's LevelA which is Beta_Solid and some interior
walls that are a lot of cubes merged together with some
differences for doorways, and there's the tubes that
connect the pods...and all of this is inside another
merge...
*listens to the thud of all of the readers of this message
as they hit the floor after having a sudden heart attack*
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
