Sluggishness? most likely my fault (code included)

BlitzMax Forums/MiniB3D Module/Sluggishness? most likely my fault (code included)

jhans0n(Posted 2010) [#1]
I've been playing with MiniB3D a bit, but I really have no clue what I'm doing with it. Anyway, I cobbled together a somewhat working movement demo as seen in the code below. (move with arrow keys, ESC to quit)

The problem I'm having with it is that while it seems to run fine untextured, if you set USETEXTURES to 1 below and give it some textures, any textures, it has periods of sporadic sluggishness, particularly when turning.

I know I must be doing something wrong. Can anyone take a look and spot the probably really obvious thing that I'm missing? 3D is definitely not my strong point, much less MiniB3D.




SLotman(Posted 2010) [#2]
Here it runs the same with or without textures.

It slows down when I turn into certain directions... maybe making it all one huge mesh isn't the best way to do it? (I would make small 'clusters' and show/hide them accordingly to camera distance)

Also, check your texture sizes... maybe a texture too big for your card to handle?

Just guessing here, sorry :(


jhans0n(Posted 2010) [#3]
Thanks for the input.

The texture size seems fine - only 256x256. I've tried bigger and smaller, but no change.

How would I go about hiding the meshes that are outside the camera range?


ima747(Posted 2010) [#4]
http://www.blitzbasic.com/b3ddocs/command.php?name=CameraRange&ref=3d_cat

CameraRange will auto cull meshes outside of the range. The further out you can push the near clip the better, and then obviously the smaller the range the better as well.

Object culling is done before the render list is pushed through opengl in minib3d. This means that if an object is totally ourside of the view, none of it gets sent to be rendered. However if any little bit might fall in view (i.e. if you have 1 huge mesh) then the whole thing gets sent and then opengl should take over with backface culling etc.

Basically the less you ask it to do (by trimming more and more) the better off you will be. However there's a point at which you will spend too much time trimming (e.g. would be if you made every surface it's own object, now it has to pre-cull everything before sending it to the renderer to be trimmed there...) Finding the right object/sufaces/tris etc. is entirely up to what you're trying to do, there's no right or wrong way, just ways that will be better with a certain goal in mind, so play with it.

I haven't looked closely through your code but from the top it looked like you were making a grid type map or something along those lines. You might find that it's best to batch say 10 squares into 1 object, this will save culling time, and enough objects would be dropped to save rendering time... just an example of why you need to toy with it for your goals.