Author |
Topic: BOX2D library for BBCSDL? (Read 395 times) |
|
michael
Full Member
member is offline
Posts: 157
|
 |
Re: BOX2D library for BBCSDL?
« Reply #3 on: Sep 23rd, 2017, 1:54pm » |
|
Quote:| I hope you realise that BOX2D is strictly 2D |
|
Yes. The renderer, regardless of the coordinate system, doesn't effect the x,y coordinates of the graphics screen.
( I checked that when working the mouse presence for each screen)
The only aspects that I would make 3D would be the spinning ball and the rotating paddles.
If BOX2D physics coordinate system is only applicable to predefined draw controls, then I guess it would be not applicable because I am aware of the shared graphics subject.
(which I am working on a remedy for 3D button controls that would have mouse interactivity. So when the mouse moves over the 3D button, a button of different texture would move slightly ahead of the main button and reverse when the mouse was away from it.)
From what I have determined, adjustment in the 3D world can be 0.01 and -0.01 to the limits of the view (on the horizontal and verticle coordinates.
So it would be a matter of working out the conversion of coordinates for mouse control, as well as location of the 3D image in a 2D location relative conversion.
|
| « Last Edit: Sep 23rd, 2017, 2:13pm by michael » |
 Logged
|
I like reinventing the wheel, but for now I will work on tools for D3D
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: BOX2D library for BBCSDL?
« Reply #4 on: Sep 23rd, 2017, 3:34pm » |
|
on Sep 23rd, 2017, 1:54pm, michael wrote:| The only aspects that I would make 3D would be the spinning ball and the rotating paddles. |
|
Ah, OK. I don't think anybody has yet used BBC BASIC to combine the Box2D physics engine with 3D-rendered graphics and that would be an extremely interesting project. There are no technical hurdles that I am aware of, and the result could be visually exciting.
If you don't attempt it I probably will!
Richard.
|
|
Logged
|
|
|
|
michael
Full Member
member is offline
Posts: 157
|
|
Re: BOX2D library for BBCSDL?
« Reply #5 on: Sep 23rd, 2017, 4:11pm » |
|
Quote:If you don't attempt it I probably will!
|
|
I have already tested the button idea. It will work. Ill have an demo ready on Monday.
That would be cool if you did work on an physics engine for 3D. I will try my hand at it regardless.
OH by the way! You may want to talk to DDRM, as he just made a shapes library for 3D (he did it lightning fast in response to my endeavours. He is interested in this also.
|
| « Last Edit: Sep 23rd, 2017, 4:19pm by michael » |
Logged
|
I like reinventing the wheel, but for now I will work on tools for D3D
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: BOX2D library for BBCSDL?
« Reply #6 on: Sep 23rd, 2017, 6:46pm » |
|
on Sep 23rd, 2017, 4:11pm, michael wrote:| That would be cool if you did work on an physics engine for 3D. I will try my hand at it regardless. |
|
I wasn't suggesting that I would do any work on the 'physics engine' itself - none is necessary really since Box2D already works with floating-point coordinates that are compatible with 3D rendering.
Quote:| You may want to talk to DDRM, as he just made a shapes library for 3D |
|
He's a member of this forum (at least, he was) so if he wants to contribute he can. There is a FNshape() function, written by me, in opengl.bbc (in the examples/graphics folder of BBCSDL) which can create vertex arrays for spheres, cones and cylinders (in fact any shape that can be described by rotating a 2D function around the Z-axis).
Richard.
|
|
|
|
DDRM
Global Moderator
member is offline
Posts: 36
|
|
Re: BOX2D library for BBCSDL?
« Reply #7 on: Sep 24th, 2017, 6:33pm » |
|
Hi Richard et al,
I've posted my current version of "Make3DLib" in the libraries section of the files section of the groups.io discussion group.
https://groups.io/g/bb4w/files/Libraries/Make3dLib.bbc
Richard, if you don't think it's finished enough to leave there, feel free to move it to the temp folder (but let us know!). It does one naughty thing - it uses a global variable to facilitate "overloading" of the routines.
You may need to be logged in as a member to get it. It's slightly updated from the version I posted on the BB4W conforum - most significantly with much better texture mapping to some shapes.
It has fairly copious notes at the beginning about what routines are included, and how to use them, and I've got some sort examples which give an idea. It can make spheres, cones,cylinders, truncated cones (and, indirectly prisms) prisms and write them either singly or en masses to an FVF file. You can include coordinates, normals, texture coordinates, and ambient and specular colours, depending on the vertex format code you specify. There are also routines to modify the shapes (shear/stretch/rotate/translate), so you can align them to make more complex shapes.
I'm interested to read about Richard's routine: that may well be better than mine, though my routines do allow you to make PART of a shape. I will add some more primitives (torus and "cove" are on my list - the latter once I work out how to calculate the external centre of curvature!
Best wishes,
D
Here's a program to generate a model somewhat like the Starship Enterprise:
Code: INSTALL "Make3dLib.BBC" capped%=TRUE :REM Include ends on the cylinder nf%=20 :REM Number of faces startface%=1 :REM Include the whole cylinder, or only part of it? endface%=10 REM Coordinates to map a texture to the shape. You might want to use only a small part of a texture texminu=0 texmaxu=1 texminv=0 texmaxv=1 maxnv%=FNGetNumVerts("sphere",nf%,1,nf%,TRUE) DIM v(maxnv%,2),vn(maxnv%,2),t(maxnv%,1) :REM hold vertex, normal, and texture data DIM vr(maxnv%,2),vnr(maxnv%,2) :REM These are only needed for the display routine nf%=10 REM We need to count up all the vertices that will be used in all the sections, so that we can put it at the beginning of the file tnv%=4*FNGetNumVerts("trunccone",nf%,1,nf%,TRUE)+1*FNGetNumVerts("sphere",nf%,1,nf%,FALSE)+4*FNGetNumVerts("sphere",nf%,6,nf%,FALSE)+4*FNGetNumVerts("prism",5,1,5,FALSE) vform%=&152 :REM Here I'm making a file with vertex, normal, and colour data fh%=FNOpenFVF("Enterprise",tnv%,vform%) nv%=FNGetNumVerts("trunccone",nf%,1,nf%,TRUE) PROCMake3D_TruncCone(1.0,0.5,nf%,v(),vn(),t(),1,nf%,TRUE,texminu,texmaxu,texminv,texmaxv) PROCStretch(nv%,v(),-0.5,1,1) REM Normals for smooth shapes are initially generated as their endpoints, so that can be scaled etc, REM So we need to carry out any transformations on them in parallel PROCStretch(nv%,vn(),-0.5,1,1) REM Now we need to convert the normals to normalised vectors vn()=vn()-v() PROCNormalise(nv%,vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF) nv%=FNGetNumVerts("trunccone",nf%,1,nf%,TRUE) PROCMake3D_TruncCone(1.0,0.5,nf%,v(),vn(),t(),1,nf%,TRUE,texminu,texmaxu,texminv,texmaxv) PROCStretch(nv%,v(),4,1,1) PROCStretch(nv%,vn(),4,1,1) vn()=vn()-v() :REM "Normals" are initially generated as their endpoints, so that can be scaled etc, but now need to be converted to vectors PROCNormalise(nv%,vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF) nv%=FNGetNumVerts("trunccone",nf%,1,nf%,TRUE) PROCMake3D_TruncCone(0.5,0.4,nf%,v(),vn(),t(),1,nf%,TRUE,texminu,texmaxu,texminv,texmaxv) PROCStretch(nv%,v(),4,1,1) PROCStretch(nv%,vn(),4,1,1) PROCShift(v(),2,2.5,2.5,nv%) PROCShift(vn(),2,2.5,2.5,nv%) vn()=vn()-v() :REM "Normals" are initially generated as their endpoints, so that can be scaled etc, but now need to be converted to vectors PROCNormalise(nv%,vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF) nv%=FNGetNumVerts("trunccone",nf%,1,nf%,TRUE) PROCMake3D_TruncCone(0.5,0.4,nf%,v(),vn(),t(),1,nf%,TRUE,texminu,texmaxu,texminv,texmaxv) PROCStretch(nv%,v(),4,1,1) PROCStretch(nv%,vn(),4,1,1) PROCShift(v(),2,2.5,-2.5,nv%) PROCShift(vn(),2,2.5,-2.5,nv%) vn()=vn()-v() :REM "Normals" are initially generated as their endpoints, so that can be scaled etc, but now need to be converted to vectors PROCNormalise(nv%,vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF) nv%=FNGetNumVerts("sphere",nf%,1,nf%,TRUE) PROCMake3D_Sphere(nf%,v(),vn(),t(),1,nf%,texminu,texmaxu,texminv,texmaxv) PROCStretch(nv%,v(),3,0.2,3) PROCStretch(nv%,vn(),3,0.2,3) PROCShift(v(),-2.1,1.5,0,nv%) PROCShift(vn(),-2.1,1.5,0,nv%) vn()=vn()-v() :REM "Normals" are initially generated as their endpoints, so that can be scaled etc, but now need to be converted to vectors PROCNormalise(nv%,vn()) PROCFindNormals(nv%,v(),vn()) :REM Cheat: something is going wrong with normals of sphere by flattening it so much: cheat by using triangles directly - OK when this flat PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF) nf%=4 nv%=FNGetNumVerts("prism",nf%,1,nf%,FALSE) PROCMake3D_Prism(nf%,v(),t(),1,nf%,FALSE,texminu,texmaxu,texminv,texmaxv) PROCRotate(v(),PI/4,0,0) PROCStretch(nv%,v(),3.5,0.5,0.2) PROCRotate(v(),0,0,-PI/2) PROCRotate(v(),-PI/4,0,0) PROCShift(v(),2.5,0,0,nv%) PROCFindNormals(nv%,v(),vn()) :REM With facetted shapes we can simply calculate the normals after all the messing around PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF) nv%=FNGetNumVerts("prism",nf%,1,nf%,FALSE) PROCMake3D_Prism(nf%,v(),t(),1,nf%,FALSE,texminu,texmaxu,texminv,texmaxv) PROCRotate(v(),PI/4,0,0) PROCStretch(nv%,v(),3.5,0.5,0.2) PROCRotate(v(),0,0,-PI/2) PROCRotate(v(),PI/4,0,0) PROCShift(v(),2.5,0,0,nv%) PROCFindNormals(nv%,v(),vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF) nv%=FNGetNumVerts("prism",nf%,1,nf%,FALSE) PROCMake3D_Prism(nf%,v(),t(),1,nf%,FALSE,texminu,texmaxu,texminv,texmaxv) PROCRotate(v(),PI/4,0,0) PROCStretch(nv%,v(),1.5,1,0.3) PROCShear(nv%,v(),2,0,1) PROCRotate(v(),0,0,-PI/2) PROCShift(v(),1.8,0,0,nv%) PROCFindNormals(nv%,v(),vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF) nv%=FNGetNumVerts("prism",nf%,1,nf%,FALSE) PROCMake3D_Prism(nf%,v(),t(),1,nf%,FALSE,texminu,texmaxu,texminv,texmaxv) PROCRotate(v(),PI/4,0,0) PROCStretch(nv%,v(),0.5,0.1,0.1) PROCShift(v(),-1,0,0,nv%) PROCFindNormals(nv%,v(),vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF804040,&FFFFFFFF) nf%=10 nv%=FNGetNumVerts("sphere",nf%,6,nf%,TRUE) PROCMake3D_Sphere(nf%,v(),vn(),t(),6,nf%,texminu,texmaxu,texminv,texmaxv) PROCStretch(nv%,v(),0.2,0.5,0.5) PROCStretch(nv%,vn(),0.2,0.5,0.5) PROCShift(v(),-0.8,0,0,nv%) PROCShift(vn(),-0.8,0,0,nv%) vn()=vn()-v() PROCNormalise(nv%,vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF804040,&FFFFFFFF) nv%=FNGetNumVerts("sphere",nf%,1,5,TRUE) PROCMake3D_Sphere(nf%,v(),vn(),t(),1,5,texminu,texmaxu,texminv,texmaxv) PROCStretch(nv%,v(),0.4,0.4,0.4) PROCStretch(nv%,vn(),0.4,0.4,0.4) PROCShift(v(),2,2.5,-2.5,nv%) PROCShift(vn(),2,2.5,-2.5,nv%) vn()=vn()-v() PROCNormalise(nv%,vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FFF04040,&FFFFFFFF) nv%=FNGetNumVerts("sphere",nf%,1,5,TRUE) PROCMake3D_Sphere(nf%,v(),vn(),t(),1,5,texminu,texmaxu,texminv,texmaxv) PROCStretch(nv%,v(),0.4,0.4,0.4) PROCStretch(nv%,vn(),0.4,0.4,0.4) PROCShift(v(),2,2.5,2.5,nv%) PROCShift(vn(),2,2.5,2.5,nv%) vn()=vn()-v() PROCNormalise(nv%,vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FFF04040,&FFFFFFFF) nv%=FNGetNumVerts("sphere",nf%,6,nf%,TRUE) PROCMake3D_Sphere(nf%,v(),vn(),t(),6,nf%,texminu,texmaxu,texminv,texmaxv) PROCRotate(v(),0,0,-PI/2) PROCRotate(vn(),0,0,-PI/2) PROCStretch(nv%,v(),1,0.3,0.5) PROCStretch(nv%,vn(),1,0.3,0.5) PROCShear(nv%,v(),-0.3,1,0) PROCShift(v(),-1.7,1.7,0,nv%) PROCShift(vn(),-1.7,1.7,0,nv%) vn()=vn()-v() PROCNormalise(nv%,vn()) PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF) PROCCloseFVF(fh%) PRINT "Success!" END |
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: BOX2D library for BBCSDL?
« Reply #8 on: Sep 24th, 2017, 9:21pm » |
|
on Sep 24th, 2017, 6:33pm, DDRM wrote:| It does one naughty thing - it uses a global variable to facilitate "overloading" of the routines. |
|
I don't think that's too awful so long as you use a 'unique' name for the global. Two approaches that effectively guarantee that are to include the name of the library in the name of the global, e.g. myGlobal@myLibrary, or to use a UUID as the name, which by definition is unique. I use the first of these in ogllib.bbc:
Code: SYS "SDL_GL_GetCurrentContext", @memhdc% TO origContext@ogllib%
Something to bear in mind is that the library may fail if the user's program, from which it is called, executes a CLEAR statement. That's not as unlikely as you may think, for example most of the 3D programs supplied with BBCSDL contain code similar to this to cope with resizing the window or rotating an Android device from portrait to landscape orientation or vice-versa:
Code: ON MOVE IF @msg% <> 5 RETURN ELSE PROCcleanup : CLEAR
Richard.
|
|
Logged
|
|
|
|
|
