3D mesh drawing and collision detection?

[XL2]

Hi!

While working on a 3D collision detection function, I noticed that it didn't make sense (at least on the CPU) trying to read through all the polygons of a mesh in a loop, only to do 80% of the same work just seconds later to draw these polygons.  It seems like it's wasting ressources. My alternative right now is to hardcode very simple bounding boxes, but it's not as accurate and it creates problems when you consider matrix translations, where the box doesn't follow unless you also code it with a function (like a moving platform). Would it be possible to add a function that does both operations at the same time (while reading a polygon to send it to the vdp1, you also look for a collision with the coordinates you passed while calling the function)? Like, while you are looping through the polygons of a mesh to calculate the vertices and send them to the framebuffer, you also look for a collision with the current caracter's bounding box? Would it be helpful to reduce CPU use?
I hope I'm making sense!
Thanks again!

[Danny]

I'm working on the 3D Space Partitioning which is also related with this.
I have been reusing some SGL examples that come with the Saturn Orbit Development package, found here http://www.rockin-b.de/windows-saturnorbit.html if you are curious, namely the "Racing" and the "Shooting" 3D examples. I tried to do some refactoring on these examples but it just seems impossible, there are a lot of "magic" numbers and I can't make sense of half of what is done there.
I mean, from the little bits I did understand of the map drawing part it looks like they are doing some sort of fustrum culling and have the map divided in areas for faster search but that's about it. The code was probably ported from assembly to C which is completely unreadable.
The collision detection used from what I understood was made like a second map with bounding areas (these areas might not match the 3d map 1:1) for example a race track only lets you move inside the track and not the rest of map,  the collision detection seemed to be done with collision sweep tests like these: http://www.gamasutra.com/view/feature/131790/simple_intersection_tests_for_games.php.
In the end I resorted to take the maps that have a lot of polygon data and try to re-use them for implementing my own 3d space partitioning.
It all falls down to how do we store the 3d map data, which is directly related to how is the 3d partitioning done, for example, BSPs and Octress can be used for collision detection.
Anyway, I wanted to help you so much but these things require a lot of study and I'm progressing at a crawling speed 

[XL2]

No problem, I appreciate all you did so far! I managed to implement some collision detection, but it's not flexible enough. The invisible mesh would probably be the best compromise, but it will take more ram also. I also tried to "call" the polygons, but it didn't go too well, sadly.

[XL2]

I'm currently starting to work on a proper octree for both collision and 3d drawing.
One issue I have is that subdividing a map for culling increase the vertices count, slowing down the Saturn.
Like, if you take a cube (8 vertices), subdivide it in 6 objects, you end up with 24 vertices.
I noticed there is an Object struct in SGL 3.0 which contains child/parents data and polygon data.
Anyone knows how to use it and if it would help?
Another option I guess could be to store polygon data in the octree's leaf and all vertices in one list, then just DMA the polygons to one single temporary mesh, but I'm not sure if it would be a pratical solution and fast enough.
Any ideas to solve that issue?