A short 3d demo

[Kman1011]

I have completed a short 3D demo showing the 3D capabilities of PB

I used the 3d engine 'Vertex Objects' lib file to calc the screen co-oords. I am using vers 1.63w

The demo is simple. Just try to reach a specific location by reading your current co-ordinates and do this within 4 minutes.
It can be done but it might take a few tries.

The controls are simple.
Arrow up-forward
Arrow down - back
Arrow L/R - Turn L/R
Mouse - Look all around (There's no limitation on camera axis so you can get disoriented)

Any problems, let me know. There are some annoying graphic anomilies I am aware of.
1 - The odd Vertex will end up in the middle of the screen looking like laser fire (but it's not)
2 - Some flicker with elevated blocks as you up move up steps
3 - I am running on an Asus G1s with an Intel core 2 duo T7500 @ 2.2Ghz and I am getting up to 18 Fps but It will choke up
at bit and drop to as low as 8 for a brief moment.


That's it

Try it out and have fun! :)

[kevin]

  Looks good and runs fairly well, so It's coming along, you can do better though :)

[kevin]

  Here's a tweaked version.  The main bottleneck is not the drawing, it's the scene projection.  It seems to be projecting 'null' cubes.  So if you screen those out, that part of the code is much quicker.   Quick enough to allow filtering.  


 

 

Download

[Kman1011]

Wow that quite a tweak. :o It's running at 60 FpS now

I see that you replaced if/end with the complier directive counterpart. This is new stuff for me.

Yes it can skip over null cubes ( which I thought I had it doing ) that would certainly help. Thanx for that!
Are you referring to drawing the program is doing offscreen?

I'm taking this step by step. Next will be to put different images onto each of the blocks. I'm not sure if going
to make a game of this. I was going to try something a little more elaborate taking advantage of being able to
rotate the camera in any direction.

The idea came from starwars Ep.6 where the Millenium falcon flew into the death star to blow up the main reactor.
I've wanted to do a game like this since I was 21. I might be able to pull it off. The only problem I keep coming
back to is collision detection. Hav'nt figured it out yet

Anyway's I'll be tinkering with this demo and learning right now.

Cheers

[kevin]

Wow that quite a tweak.  It's running at 60 FpS now

   Amazing what an IF statement can do :)

Yes it can skip over null cubes ( which I thought I had it doing ) that would certainly help. Thanx for that!
Are you referring to drawing the program is doing offscreen?

  Well, I didn't actually take the time work out exactly how you've gone about it, but when i looked at the routine to draws the scene around the the camera.   It seemed to be falling through the this process regardless, which was confirmed after timing the routine.

  Originally it was eating about 70 milliseconds on my machine.   So screening seemed like the easiest way to eliminate any unnecessary iterations.   The routine is still expensive, but pre-screening makes it about 60% faster.   The routine takes about 15->25 milliseconds.   

   You could take this further, one idea could be be check the radius from the viewer (camera).  Since the camera is spherical volume, and we're throwing a cubic volume (cut up into cubes) at it,  some of the outter cubes, won't be visible.   So these could be early rejected, but checking the distant from the camera and the center of the cube.   The early reject,  will save this outter cubes from falling through the CheckMap routine.   Which seems to contain some redundant calculations.   So you might be able to simply restructure it and win back some performance.

   Moreover, you could sub divide the would into smaller cubic volumes further.  By that i mean,  you could make a second map, this map is 1/2 the resolution of the world map.  This map would hold the cube of 'active' cubes within this volume.   So it's represents a 2*2 block of the world map.  So in one test we can eliminate whole volumes from consideration.    Which basically how Octree systems work. 

   In terms of the offscreen stuff, you could also early detect if a volume falls behind the camera,  if it is, toss it. 

The idea came from starwars Ep.6 where the Millenium falcon flew into the death star to blow up the main reactor.
I've wanted to do a game like this since I was 21. I might be able to pull it off. The only problem I keep coming
back to is collision detection. Hav'nt figured it out yet

      Collision is generally cheated in 3D.   Visuals and collision environment are two different things.   In an elite styled game, where the player is flying around in space, the detection is pretty simple.  Sphere intersection (object to object / early rejection),  Ray to Sphere (bullet to object) for example.    So were not testing the polygons just representative surfaces.     Polygon to Polygon intersection is pretty challenging to do fast.     So often collision is performed upon very low poly or geometric shapes to approximate the objects hull.   So to detect and impact we might fall through various levels of trivial rejection..

   

[Kman1011]

I was thinking about the cubes projected offscreen and wether or not it took time to draw them, but i thought, if its not on the screen then I don't have to worry about it. I guess I was wrong but I could not figure a way to filter out unneccessary blocks. Just ones that needed no surface drawing.

Which seems to contain some redundant calculations.

I know. I'm the king of redundency! :( It's part of my process to see this and elimnate them like the routine -GetObjectAdress.

Well.. Thanx. I'll see what I can do here

BTW- if you change the variable DemoMode to true U will see a different view of the project. more of a skeletal form for which to do diagnostics.

[kevin]

 

I was thinking about the cubes projected offscreen and whether or not it took time to draw them, but i thought, if its not on the screen then I don't have to worry about it. I guess I was wrong but I could not figure a way to filter out unnecessary blocks. Just ones that needed no surface drawing.

   Yeah, I understand the assumption and would have said the same thing once.   But it's critically important to cull geometry quickly, ideally before rotation and way before drawing the polygons.   The more we can remove in the less calcs,  the more complex the overall world can be.    As even if processing an object only takes a small amount of the overly processing time, this time is magnified the more content we try and handle.   So it's still burdening us.  

Given the amount of vertex access, you'd probably benefit from this type of approach when dealing with lots of verts.
Rotate Vertex List Directly Into Arrays

[kevin]

 Kman1011 3D engine Demo From 2009


I found this capture of Kaman1011's 3D demo on an old external HD that was (as far i remember) never uploaded on the channel, so here it is 10 years later for all of your PlayBASIC nostalgia :)


 

  Original 2009 Capture
 

Music Missive by Andrew Langdon