I am creating a tool for modeling architecture/building information in
POV-Ray SDL. I am implementing the ability for the walls to clean up (form a
clean connection regardless of angle) with each other.

I am currently using planes and although it is still too early to notice memory
problems I was wondering if this is the right direction. The building walls are
mainly made of boxes while the floors (most parts) are made of prisms. As you
can imagine there will potentially be a lot of instances for this use (i.e.
clean up).

I have not tried triangles (I have read so much about it being efficient) but I
have read so much too about it not being so stable for CSG operations.

Any insight on this from anyone?

Post a reply to this message

"Kene" <nomail@nomail> wrote:
> I am creating a tool for modeling architecture/building information in
> POV-Ray SDL. I am implementing the ability for the walls to clean up (form a
> clean connection regardless of angle) with each other.
>
> I am currently using planes and although it is still too early to notice memory
> problems I was wondering if this is the right direction. The building walls are
> mainly made of boxes while the floors (most parts) are made of prisms. As you
> can imagine there will potentially be a lot of instances for this use (i.e.
> clean up).
>
> I have not tried triangles (I have read so much about it being efficient) but I
> have read so much too about it not being so stable for CSG operations.
>
> Any insight on this from anyone?

I have realized that a merge does this work well enough with some recalculation
to get the new intersections. This seems to make more sense at this point.

Post a reply to this message

Kene wrote:
> I have realized that a merge does this work well enough with some recalculation
> to get the new intersections. This seems to make more sense at this point.

One thing to be careful of is if you're using actual shadow-casting lights 
instead of ambient or some such. If you build the entire building out of one 
object (e.g., a union of walls and floors), the shadow calculations will 
take forever. Each light will have to test every object in the entire 
structure for each ray cast.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:

> One thing to be careful of is if you're using actual shadow-casting lights
> instead of ambient or some such. If you build the entire building out of one
> object (e.g., a union of walls and floors), the shadow calculations will
> take forever. Each light will have to test every object in the entire
> structure for each ray cast.

Thats good to know but I am good so far. I am trying to be as simple as possible
in this project so am using only boxes and prisms so far. The only CSG is on the
creation of curved walls and also in my plan for windows and doors. I suspect
also parts of the roof. I have discarded the plan for using merge at
intersections also. Prisms work very nicely.

It is important to model most items as single items because of the information
management part of the tools. I need to know precisely where things are so that
a flat drawing (plan and elevations can be extracted later).

Thanks for the comment.

Post a reply to this message

> "Kene"<nomail@nomail>  wrote:
>> I am creating a tool for modeling architecture/building information in
>> POV-Ray SDL. I am implementing the ability for the walls to clean up (form a
>> clean connection regardless of angle) with each other.
>>
>> I am currently using planes and although it is still too early to notice memory
>> problems I was wondering if this is the right direction. The building walls are
>> mainly made of boxes while the floors (most parts) are made of prisms. As you
>> can imagine there will potentially be a lot of instances for this use (i.e.
>> clean up).
>>
>> I have not tried triangles (I have read so much about it being efficient) but I
>> have read so much too about it not being so stable for CSG operations.
>>
>> Any insight on this from anyone?
>
> I have realized that a merge does this work well enough with some recalculation
> to get the new intersections. This seems to make more sense at this point.
>
>

Unless you are working with transparent walls that have 
intersecting/overlaping parts and you need to remove the internal faces, 
use union instead of merge. It's much faster. With an union, you only 
test for the components that occupy a given, limited, area. With a 
merge, you always have to test for every components.

If you create all your walls with a corner aligned to a reference plane 
(one edge with a zero coordinate) and you rotate them to the desired 
orientation then translate to the desired location, it's easy to have 
them join cleanly.

If you use triangle, they don't have an interior. You can't use them to 
remove something from something else. You can chop bits from it. You can 
definetly union them with anything.
You can combine many triangles into a mesh, and it can have a definite 
interior, you just need to add an "inside" vector. That way, it can be 
used in CSG without any problem. If you have many walls all defined 
using the same mesh, the mesh will reside in memory only once and will 
be referenced as needed with some transformations. Meshes also render 
fast, but a box is one of the most effecient primitive regarding 
rendering speed.

When you mention "a lot of instances", you think of what order of 
magnitude? POV-Ray can easily handle 100000's, or even millions, 
individualy textured boxes in a single scene, plus 100's of different 
prisms.


Alain

Post a reply to this message

> Unless you are working with transparent walls that have
> intersecting/overlaping parts and you need to remove the internal faces,
> use union instead of merge. It's much faster. With an union, you only
> test for the components that occupy a given, limited, area. With a
> merge, you always have to test for every components.
>

I am using a union of boxes and prisms for all unclean joints.

> If you create all your walls with a corner aligned to a reference plane
> (one edge with a zero coordinate) and you rotate them to the desired
> orientation then translate to the desired location, it's easy to have
> them join cleanly.
>

Imagine a +45 degree slanted wall connected to a 0 degree one. This will result
in an unclean connection. The spaces around the connection has to be filled and
some parts cut off. This is the problem I was describing. Also, the dimensions
need to be extracted for automatic creation of clean 2D flat drawings that are
construction document-level quality. Maybe they can be combined with another
drawing (as references) after extraction from POV-Ray but I do not want them to
be brushed-up or cleaned.

> If you use triangle, they don't have an interior. You can't use them to
> remove something from something else. You can chop bits from it. You can
> definetly union them with anything.
> You can combine many triangles into a mesh, and it can have a definite
> interior, you just need to add an "inside" vector. That way, it can be
> used in CSG without any problem. If you have many walls all defined
> using the same mesh, the mesh will reside in memory only once and will
> be referenced as needed with some transformations. Meshes also render
> fast, but a box is one of the most effecient primitive regarding
> rendering speed.
>

I wish to keep away from triangles although I feel that I will use them in the
roof construction. I get a headache handling them... for now.

> When you mention "a lot of instances", you think of what order of
> magnitude? POV-Ray can easily handle 100000's, or even millions,
> individualy textured boxes in a single scene, plus 100's of different
> prisms.

A typically residential building (which is my focus for now) would probably use
a few hundred boxes. I am also modeling finishes as boxes because I need to
calculate construction cost, etc.

Post a reply to this message

Actually, am still using planes to cut the parts that need to be removed in the
connection. So a part of my original question is still valid. Is it OK regarding
memory, using so many planes in a scene (a few hundreds for sure)

Post a reply to this message

> Actually, am still using planes to cut the parts that need to be removed in the
> connection. So a part of my original question is still valid. Is it OK regarding
> memory, using so many planes in a scene (a few hundreds for sure)
>
>
A plane don't use much memory:
- A directional vector (a group of 3 floats)
- A distance from the origin (a single float)
- possibly a texture
- possibly some transformation

You'd need many thousands, even millions, before your planes start to 
cause memory isue. So, several 100's is entirely OK memory whise.

I rendered scenes with over 100000 individualy textures spheres without 
problem. Note that a sphere uses about the same amount of memory as a plane.


Alain

Post a reply to this message