|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Timothy R. Cook" wrote:
> It seems to me I read somewhere that merges were faster...?!
http://www.students.tut.fi/~warp/povQandT/miscQandT.html#csgspeed
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 14 Feb 2002 21:36:41 GMT, Erk### [at] povrayorg (Erkki
>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.
I've often thought about a possible remedy of the situation and the
only thing I've come up with is the following:
Imagine the scene space split into 27 subspaces by the 6 planes that
define an object's bounding slab. The central subspace is finite and
the others are infinite but have some defined boundaries. When
calculating the bounding slabs for a difference, there will be 26
slabs (at most) in the hierarchy and not 1, but it could be faster
than no bounding at all (for the internal objects).
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> *listens to the thud of all of the readers of this message
> as they hit the floor after having a sudden heart attack*
Don't worry, at least - I - didn't get a heart attack.. I doubt anyone did..
Well, what you're doing looks fine, but DO change merge to union and I think
you'll be surprised of the speed gain. :o) As I don't know how Moray
works, I can't say if the code will then be fully optimised, but anyway!!
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hugo wrote:
> Well, what you're doing looks fine, but DO change merge to union
> and I think you'll be surprised of the speed gain. :o)
Did, and did. 11 minutes with lights added as opposed to 2 hours
without...
Is it a bad thing if you're only 1% done with a render after 10
hours? Only thing is, it looks SO cool! (see povray.images for
current state of it)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Is it a bad thing if you're only 1% done with a render after 10
> hours? Only thing is, it looks SO cool! (see povray.images for
> current state of it)
It does look cool! ...mmhmm 10 hours ... I am without words...
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |