It's nothing fancy, just the (little) revised code found in another thread, written in a tutorial-like manner. The controls for the demo are detailed in the readme.md file. The complete discussion can be found here: 3D without OpenGL.

It is little more than a playground, and serves mainly to illustrate different coordinate systems and how they relate to each other. It can also be used as a sort of debug-mode for computational geometry algorithms and stuff like that. Perhaps I'll refactor it someday, to really make it usable for anybody as a base for a 3D engine.

BC2, that seems like an error generated by your IDE. I get similar results when FbEdit can't delete the temporary instance from a previous QuickRun. Works fine here, tested it before publishing the link ;)

lizard wrote:Works here on Mint with ~440 fps.

Cool! I need to get a new box. I get 80 fps here =D

Haubitze wrote:nice work paul doe,

i used it for an galaxy generator with MST building, the building of the MST takes a while.

Thanks. Wow, that was a fast response =D

May I suggest that you remove the paper plane, the floor and the axes? They just get in the way of an otherwise beautiful demo =D

intended as a simple tutorial/framework to do 3D stuff without too much complication it is a bare-bones implementation, actually. Mostly to test all the math/conventions behind the representation of a 3D scene (using the term 'scene' veeeery loosely here)

conventions used RIGHT HANDED coordinate system positive rotations are COUNTER-CLOCKWISE facets are defined in COUNTER-CLOCKWISE order angles are in RADIANS - use radians( angle_in_degrees ) for convenience'/'' set a screen mode

the projection plane is where the image gets projected (duh) in the pinhole camera model, the projection plane is actually the so called 'near' plane. The near parameter of the camera is really the distance of this plane to the origin of coordinates (in the case of the camera, its position in the world coordinate system'/dim as rectangle projectionPlane = ( 0.0, 0.0, scrW, scrH )

/' instantiate a camera class remember the parameters for the constructor:

position, in WORLD space X axis of the camera's coordinate system Y axis of the camera's coordinate system Z axis of the camera's coordinate system. If you flip it, you will end with a left-handed coordinate system. Not that it matters much, save for the fact that all other methods treat the matrix as a right-handed one. If you use lookAt() and suddenly the axes get flipped, this is the most probable reason near clipping plane Z distance far clipping plane Z distance projection plane

a word of advice: the axes of the camera have to be of a certain length, for the projection matrix depends on it. See the code below, where the U and V vectors get scaled to match the relation of the projection plane. If you fool around with them and suddenly the image looks like crap, this is the most probable reason.

to remember: the U vector (the X one) controls the horizontal field of view the V vector (the Y one) controls the vertical field of view and the Z vector controls the zoom

of course, they must be perfectly perpendicular to each other, if not the resulting image is sheared. Anyway, you don't have to mess with the constructor if you don't like and/or understand what it does for the camera to do its job.

having said all that, play around! See how each function transforms the camera, and the effect it has on the image. Look at the implementation to see how it's done, but most important of all, have fun!'/dim as cameras cam = cameras( _vec4( 0.0, 0.0, 3.0 ), _vec4( 1.0, 0.0, 0.0 ), _vec4( 0.0, 1.0, 0.0 ), _vec4( 0.0, 0.0, -1.0 ), _0.1, 10000.0, projectionPlane )

/' scene manager (yeah right)

here, it's just a list that contains the objects to be rendered, but in real code it is an instance of the scene manager.'/dim as arrayList objects

these are the vertices and edges to define a small paper plane that you can manipulate (see the code in the main loop) the objects ideally should be loaded from a file, but that will complicate the implementation. If there's some interest, I will show how you can load an obj file (or invent your own format if you wish)'/dim as object3d ptr obj = new object3d() '' it will be at the origin, at the start

Dim line_pattern(0 To 15) As UShort={&b0000000011111111,&b0000000111111110,&b0000001111111100,&b0000011111111000,&b0000111111110000,&b0001111111100000,&b0011111111000000,&b0111111110000000,&b1111111100000000,&b1111111000000001,&b1111110000000011,&b1111100000000111,&b1111000000001111,&b1110000000011111,&b1100000000111111,&b1000000001111111}

screenUnlock() ScreenSync /' it's important not to let this var to be negative, as it gets multiplied with the camera vectors and could screw some calculations (movement, for example) told you, the loop implementation is very crappy, but it seems like this is esier for most people to grasp '/ frameTime = abs( timer() - frameTime ) sleep( 16 )loop until multikey( fb.sc_escape ) '' loop until esc is pressed

i have a question about camera position. i need to turn a camera around a point. so i can "orbit" him.in BlitzBasic3D i think i use lookat and move. but i cant build it in your engine.

can you explain how i can orbit an point with a given distance with an camera?

thanks for this nice work :)

salute

PS: i refactor my demo, the MST is build one or two bits faster. also i have an preview of the generated galaxy in realtime(sGUI is used to get the parameters). but i will make it look nice this is why i ask about the orbiting thing.also i plan an a* pathfinder so you travel from one point to another between the connections shown on the sceen.

Here a little update on my Demo, i think the MST is build a bit faster. i also have adjust the colors a bit.but my A* algo do not the work i sugested :(

eventualy anyone can tell me what i make wrong. but i have to say the code isnt commented an its not clean to this time.my first thinking was that my heuristic function was the error but now i think it is how i build the node-graph.

Haubitze wrote:... anywai, pls take a look and send me an report how it runs ...

Compiles on linux when I replace inc with Inc on line 2 and 3.But with -w all -exx compile option i get:Aborting due to runtime error 1 (illegal function call) at line 124 of /home/badidea/Downloads/FreeBASIC/3DGame/Inc/sGUI/ScrollBar_Basis.bas::DRAWSB()With a normal compile, it seems to run smooth, but I don't see any FPS.Also, the keys (e,q,w,a,d,s) don't seem to do much,

You can do the same here, but you get 'drifting' due to the crappy precision of the singles and the fact that the code uses in-place array modification and does not perform any kind of orthonormalization every once and then, so distances tend to drift and axes tend to become skewed. A better approach is simply to load the identity vectors and construct the matrices again from scratch (like the old OpenGL fixed-function pipeline did, if you programmed it back in the days).

Or, you can compute and apply the transformation matrix yourself. Remember it was:

Translate the object you want to rotate to the position you want to orbit around.

Perform the rotation around the axis you want.

And then translate back in that direction.

I think I have a better version of this crap lying around, but couldn't find it for the life of me. If there's some interest, I shall rework this little demo (it was coded in a real hurry, and it shows) into something a little more manageable and useful, with a scene manager too (complete with frustum culling) so it can really be used as a base for some more advanced. I don't know, I've been pretty busy with other things recently, sorry =D

Haubitze wrote:Here a little update on my Demo, i think the MST is build a bit faster. i also have adjust the colors a bit.but my A* algo do not the work i sugested :(

eventualy anyone can tell me what i make wrong. but i have to say the code isnt commented an its not clean to this time.my first thinking was that my heuristic function was the error but now i think it is how i build the node-graph.

anywai, pls take a look and send me an report how it runs.

I have something on that that you can use. Hang on, I'll prepare a little code you can study. Do you prefer plain A*, or something more like a Vector Field Pathfinding? Which one could be more useful to you? There are some implementations of A* here in the forum, but I hadn't seen one for Vector Fields, so I suppose it would be this one =D

About how it runs: runs nice... for a while, then crashed. Badidea above provided a nice debug info about where to look first.

hey badidea and Paul Doe, thanks for testing. in the next demo i will show an FPS counter.

for the A* i think an Plain A* where enoug for me. if i create hundreds of ships and they are all searching for an path to another targetthen i think Vector Field Pathfinding is a bit to much.

the rotation problem is solved and i think i implement it how you say Paul.

the sGUI problem i will look at it if i cant solve it i have to speak to Muttonhead.i also will take a look why it crash after a time.

so far so good ;)

Edit: so now i think the crash is gone, it was my fault i updated the targets for the flying but dont generate it.i also delete all the old stuff in the file so you dont get confused.the sGUI error badidea becomes with "-w all -exx" i cant reproduce. im on win10 with fbc 1.05.0 32bit.the project are also updated, see link above.

Haubitze wrote:for the A* i think an Plain A* where enoug for me. if i create hundreds of ships and they are all searching for an path to another targetthen i think Vector Field Pathfinding is a bit to much.

Quite on the contrary. It was developed precisely to allow hundreds of units to do pathing all at once. It's simple to implement, and extremely efficient. I'll see if I can show you an implementation soon.

Haubitze wrote:the rotation problem is solved and i think i implement it how you say Paul.

Glad to hear it. Or, it dawned on me that you can also implement it as a positional and rotational constraint (been doing some physics code =D).

Haubitze wrote:Edit: so now i think the crash is gone, it was my fault i updated the targets for the flying but dont generate it.i also delete all the old stuff in the file so you dont get confused.the sGUI error badidea becomes with "-w all -exx" i cant reproduce. im on win10 with fbc 1.05.0 32bit.the project are also updated, see link above.

now i generate solarsystems using this resource http://sol.trisen.com/downloads/wg.pdf.if i get in to an sector i try to render the system. but all is to far away (so it is to small to see it).it uses for Stars this measurements

but it dos not help to get a good result.if anyone have an idea how to scale it down to get a good result i will be happy.or if anyone have an idea how to render it to see the details of the system without destroy the informations behind it i also will be happy.

PS.: also the pathfinding has spartialy gone and the source is unclean again.the systemgenerator is from another project form me. so it will not use the paul doe's arrayList.PPS.: an request to paul doe, for an object i think an z sorted drawing where an nice feature ;)