[Papervision3D] objects to Object

[Jon Bradley]

Agreed... but remember that BSP trees don't need to have any user  
interaction with them.

A BSP tree should be automatically adjusted as assets are added to  
the scene. General users would have nothing to do with the tree or  
scene structure, as that shouldn't be exposed to that level of  
interaction. It's an internal engine structure.

BSP trees are an all or none proposition. It's something that needs  
to be integrated fully if you want to realize its potential. I don't  
think it is something you would want to use for certain scenes.

my 0.02.

jon



On Jan 15, 2007, at 9:46 AM, Carlos Ulloa wrote:

> I believe that bsp trees are our best solution for rendering  
> environments, but for generic scenes I think it's better to start  
> with a simple tree structure of groups. Afterwards we can add bsp  
> trees as an option.
>
> I've been thinking a lot about the 3d learning curve ahead for the  
> typical flasher. IMO it would make sense to introduce first the  
> features that are easier to use, so people can get into it with a  
> minimum effort.
>
> C4RL05
> // noventaynueve.com
> // papervision3d.org
>
>
> On 15/01/07, Tim Knip <tim.knip at gmail.com> wrote:
> How about a simple BSP-tree structure?
> Could be per mesh or by 'all faces'...
>
> Disadvantages:
> 1. some faces need to be splitted.... yielding about 1.5 times more  
> faces.
> 2. more suited for static scenes, movement would involve inserting
> nodes into the tree @ runtime.
> Advantages:
> 1. z-sorting is always near perfect (just walk the tree with the  
> cam-position).
>     => large faces don't have to be triangulated (if you accept  
> persp-distort)
>     => easily can use quads
> 2. creating the tree is an offline-process...
> 3. simple to code
>
> T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/papervision3d_osflash.org/attachments/20070115/b8840ac4/attachment.htm