[pythian] Re: CODE - BSPs and Cal3D
- From: "kk" <krauspe@xxxxxxx>
- To: <pythian@xxxxxxxxxxxxx>
- Date: Thu, 13 Jun 2002 12:54:07 +0200
> This should work as long as the you don't cull faces based on the
> velocity and the normal. It must be all panels within the range of the
> velocity in *any* direction. Then it should be fine to only calculate
> this once.
Yeah... this is the potential bug I was talking about
> >I have also reimplemented user per - node contents box for physics tree.
> >This speeds up the physics engine a bit as it elliminates up to 70% of
> >panels in some cases. This is due to fact that some nodes are a lot
bigger
> >(the determined node box) as their contents.
> >
> Yes, I understand. How much memory does this take? You talk about
> reducing the size of the map files, but this will surely increase it a
> lot when we build the tree during export... Anyway, if it makes a huge
> difference for speed, perhaps instead we should increase the depth of
> the physics tree instead. After all, that is the point of having a
> tree, right? If we increase the depth, we will have less false-positive
> panels.
It is saved not per panel but per node. That means it takes (2^10 - 1) *
(SizeOf(TBoundingBox) + 4) = something less than 30kB.
> What are the advantages of patches? I thought you had only included
> them so we could import Q3 maps... however, I'm not even sure why we
> want to import Q3 maps. Won't we design our own maps in MAX? Either
> way, why do we care about patches?
I have done the q3 importer to test the patches. The patches are very good
to use as they can reduce the number of rendered polygons. In fact it DLOD
is the most important feature of the patches. The patches also cut down also
the size of the map. They just save the controlpoints (e.g. 3x3 or 4x4 or
9x9 single3d values).
It is also a way to implement DETAIL LEVEL. Some video cards are enough fast
to render the patches super smooth but some aren't. Are we going to limit
the number of polys just to have the scene rendered fast also for the slower
cards? It would look good for the fast cards. And vice versa. This is what I
am talking about. Also physics engine is important here. Level of detail 1
or 2 (less subdivisions) patch will be used for the physics engine. (higher
LOD = more subdivisions).
> Ok, so to answer your question about committing: you can commit your
> changes to the physics and the textures right now. I don't agree with
> storing a bounding box for every single panel, so let's try to increase
> the depth of the tree instead. Don't commit that change for now. I
> would like you to move all the code for the patches, patchgroups, and
> patchtrees, into a different file out of Maps.pas. Maps.pas is becoming
> far too cluttered. I may do the same for the panel strips.
Ok, I will divide both patches and strips into two other files.... It would
be waste of my time to commit current changes and let you divide the
maps.pas and then reimplement everything from stratch... I will probably
also commit the changes to the physics engine with the bounding boxes so you
can look into it once more and if it isn't good I will remove it... it is
easy to do...
Tell me what do you think...
-kk
Other related posts:
