Author Topic: Glib : a 3D graphics axe library (Read 79682 times)

TheMachine02 · « **Reply #300 on:** January 06, 2014, 01:02:31 pm »

baf

. The scene complexity on this calc is not so high so z ordering is enough. Z buffer couldn't be achieve, cause it require a way to much ressource (per pixel check , and a big ram buffer (+-12000 bytes for 16-bit precision...)

ben_g : I will add that then

Since 3D clipping and z-ordering require caching vertices, I guess I will do that

ben_g · « **Reply #301 on:** January 06, 2014, 01:05:19 pm »

Z-ordering is indeed not perfect, and (while the problem seen in that image is very uncommon) it won't be able to draw intersecting polygons correctly. If you want to draw it correctly, you'd need Z-buffering, which needs a lot of RAM. And unfortunately, the 83+/84+ hasn't got much ram.

EDIT:

TheMachine02 · « **Reply #302 on:** January 07, 2014, 06:29:01 am »

program example of vertex buffer object or VBO for short. Does syntax is good ? It is cleaner ?

Code: [Select]

.TEST
prgmGCORE

Data(40r,-40r,40r)→GDB1
Data(40r,40r,40r
Data(-40r,-40r,40r
Data(-40r,40r,40r
Data(40r,-40r,-40r
Data(40r,40r,-40r
Data(-40r,-40r,-40r
Data(-40r,40r,-40r

Data(0,1,2,3,4,5,6,7)->°LinkList
Data(0,2,2,4,4,6,6,0
Data(1,3,3,5,5,7,7,1


GNewCam(°GMODELVIEW)
GGenBuffer(8)→G    //take in argument number of vertices and return an id OR 0 if fail
Return!If

GBufferData(GDB1,G,8)   //data to copy, id, size in vertices.

While 1

GUpdateBuffer(G)   //take id

For(M,0,11)    .there is 12 line to draw in a cube
GClipLine({M*2+°LinkList},{M*2+1+°LinkList}
End


GGetkey()

DispgraphClrdraw
EndIf getkey(15)

note too that I have slighty change GGetkey() syntax.

ben_g · « **Reply #303 on:** January 07, 2014, 12:22:28 pm »

so, GUpdateBuffer(id) transforms all the vertices? That seems like a quite simple syntax, but when the amount of vertices changes, do we have to generate a new buffer every time? Because that sounds kinda slow

Matrefeytontias · « **Reply #304 on:** January 07, 2014, 12:24:20 pm »

I guess creating a buffer is actually creating an appvar, so doing it on-the-fly is kinda slow yeah. There's also the fact that you can arrange your code so that you don't actually generate VBOs on-the-fly.

TheMachine02 · « **Reply #305 on:** January 07, 2014, 12:25:40 pm »

indeed, I didn't think about this. So something like :

Code: [Select]

GBufferUpdate(id, start_update,end_update)

with start_update the first vertex to update, to end_update ?

Matrefeytontias · « **Reply #306 on:** January 07, 2014, 12:26:56 pm »

I think it shoud do yeah. But you can actually have several VBOs running at once ?

TheMachine02 · « **Reply #307 on:** January 07, 2014, 12:30:04 pm »

yep, you can generate up to 255 VBO, and choice wich one to activate with id . You can also delete them - but this only free memory ; meaning that even if you have suppress some VBO ; you will not be able to generate other if in total you have generated 255 VBO. Hope you will understand me

Matrefeytontias · « **Reply #308 on:** January 07, 2014, 12:31:48 pm »

Yeah, if you generate 255 VBOs then delete one, you still can't generate any more.

TheMachine02 · « **Reply #309 on:** January 07, 2014, 12:32:55 pm »

exactly that

cause handling remplacement woud be a way to much difficult (and heavy).

Matrefeytontias · « **Reply #310 on:** January 07, 2014, 12:34:52 pm »

Well, I don't know how you handle them, so I can't really say. I don't think anyone will need to generate more than 1 or 2 VBOs though

Something that I just thought of : are you able to rotate a vertex around a custom point ?

TheMachine02 · « **Reply #311 on:** January 07, 2014, 12:45:00 pm »

using custom camera, yes. Basically , you create a new camera ; rotate point around this camera , go back to the classic camera , and render point.
For example ; if I want rotate point 10,10,10 around X,Y,Z, with angle A B and have a world camera, I could do something like that :

Code: [Select]

GNewCam(°GWORLDVIEW)

While 1

GNewCam(Data(Ar,Br,Xr,Yr,Zr,0r))

GRotate(10,10,10)
GDelCam()

GVertex({°GVertex}r,{°GVertex+2}r,{°GVertex+4}r)
Pxl-on(,{°Gvertex+2}r)

GGetkey()

DispgraphClrdraw
EndIf getkey(15)

however ; in the next version of GCORE , the format of the camera will slighty change (nothing big) ; that why I still doesn't made a tuto about it.
The engine in itself can handle 2 different camera.

EDIT this code work for the "old" version though

Matrefeytontias · « **Reply #312 on:** January 07, 2014, 12:47:24 pm »

Okay, that'll be helpful for full models animations, things like wheels and stuffs.

TheMachine02 · « **Reply #313 on:** January 07, 2014, 02:00:24 pm »

After some test, seem that VBO is almost as fast as "classic" code. So I will keep that

. I have to try with dot point, though cause acessing it will be more slow

EDIT : ok so it seem that with dot , VBO run at 53-54fps (classic cube) ; and without it run between 55-56 fps (without any super secret settings :p). However, I didn't optimize *yet* the VBO's code

TheMachine02 · « **Reply #314 on:** January 11, 2014, 09:41:11 am »

finally achieve *perfect* 3D cliping !
however, it's kinda more slow than only doing z plane cliping so, I have to still work on it.

Some pic who will speak better than me

BEFORE : AFTER:

Author Topic: Glib : a 3D graphics axe library (Read 79682 times)

TheMachine02

Re: GLIB a graphics axe 3d librairy

ben_g

Re: GLIB a graphics axe 3d librairy

TheMachine02

Re: GLIB a graphics axe 3d librairy

ben_g

Re: GLIB a graphics axe 3d librairy

Matrefeytontias

Re: GLIB a graphics axe 3d librairy

TheMachine02

Re: GLIB a graphics axe 3d librairy

Matrefeytontias

Re: GLIB a graphics axe 3d librairy

TheMachine02

Re: GLIB a graphics axe 3d librairy

Matrefeytontias

Re: GLIB a graphics axe 3d librairy

TheMachine02

Re: GLIB a graphics axe 3d librairy

Matrefeytontias

Re: GLIB a graphics axe 3d librairy

TheMachine02

Re: GLIB a graphics axe 3d librairy

Matrefeytontias

Re: GLIB a graphics axe 3d librairy

TheMachine02

Re: GLIB a graphics axe 3d librairy

TheMachine02

Re: GLIB a graphics axe 3d librairy