LoginLogin
Might make SBS readonly: thread

Poly3D

Root / Submissions / [.]

kevinfoleyCreated:
Download:CPC3Q3CJ
Version:1.3.0Size:263 KB
Poly3D is a flat-shaded 3D engine for SmileBASIC. The engine supports flat-shaded polygonal 3D models defined with triangles (no lighting support). It is a lightweight engine optimized for performance. This engine evolved from my earlier Wire3D engine. Performance tests (New 3DS, rendering rotating models, no gameplay code): 0 - 190 triangles onscreen: 60fps 190 - 390 triangles onscreen: 30fps 390 - 630 triangles onscreen: 20fps 660 triangles onscreen: 15fps Version 1.3.0 (12 March 2024)
  • Model Editor: Added buttons for copy/pasting face colors (this was in 1.1.0 release notes but not actually implemented?)
  • Model Editor: You can now press ZL to show vertex IDs for all vertices
  • Model Editor: In Face Mode, added a white line to show face normal (only relevant for 3DO export)
  • Model Editor: Added a button for exporting models in the 3DO format used by Star Wars: Dark Forces. You would then need to transfer the model to a PC using PetitModem or similar.
  • Model Editor: The size of the current model (in numeric values) is shown in the upper-right corner. Each vertex is 3 values (x/y/z) and each face is 6 values (3 vert indices and R/G/B color channels).
  • Model Editor: Added a Help button.
  • Model Editor: Major fixes to Undo/Redo functionality.
  • Model Editor: Other minor UX improvements.
Version 1.1.0 (13 December 2018)
  • Added FIRSTPERSON example game. Move around and shoot targets as fast as possible. Demonstrates depth-sorting, 3D camera movement and rotation, and basic collision detection. 60 fps on a New 3DS
  • (No engine changes)
Version 1.1.0 (2 November 2018)
  • Added STARBLITZ example game. Fly your spaceship and avoid the obstacles. Demonstrates depth-sorting, 3D movement and rotation, and basic collision detection. 60 fps on a New 3DS
  • Engine, Model Editor: Fixed numerous issues with axes being double-or-triple reversed
  • Model Editor: Fixed vertex movement controls sometimes being reversed
  • Model Editor: Reversed the z-axis. Now the coordinate system behaves like Blender 3D, as I had originally intended
  • Model Editor: Added some parsing code for OBJ files (not tested; how would I get an OBJ file into SB in the first place?)
  • Model Editor: Added buttons for copying and pasting face colors
  • Many other minor bug fixes
Version 1.0.1 (24 October 2018)
  • Fixed error if you deleted all faces from a model
  • Fixed slider values being constantly reapplied until you tapped somewhere else on the touch screen
  • Save/Load remembers the last file name you entered, so that you don't have to keep re-typing it each time you save
  • Added an example model Pumpkin.3D
Version 1.0 (24 October 2018):
  • Rewrote Poly3D into a compact common library that can be easily used by other programs
  • Added Poly3D Model Editor v1.0 (compatible with New 3DS or Circle Pad Pro). This is a simple model editor with limited features, but should be good enough for creating simple models. - Create 3D models with colored faces - Save / Load 3D model files - Camera controls - In addition to the main camera, the model is displayed as a wireframe in three orthogonal views (Front, Left, Top) on the touch screen - Undo / Redo functionality
  • Added a GUI library which can be used to draw interactive buttons, checkboxes, and sliders on the touch screen Note: I released this latest update much earlier than I was planning, so that others can use the included model editor. This version does not contain any other example projects. I am hoping to release another update sometime in the next month or so with additional examples of the engine in use, but can't make any promises. Hopefully I won't disappear for 3 years again! :)
Version 0.8 update: *Supports rotation on all 3 axes (uses Euler rotation and suffers from gimbal lock, so I don't recommend rotating on all 3 axes at the same time) *Uses GPAGE buffer to eliminate draw flicker (thanks Trinitro!) *Fixed support for multiple models in a single scene *Added two new models, a cube and a Starwing, which definitely isn't borrowed from any old Nintendo games *Added more models and animations to the sample scene to better demonstrate the engine. The sample scene includes over 200 polys and runs at 60fps on a New 3DS Version 0.7 (initial): *Supports 3D models with per-face coloration *Supports instancing models, reducing memory usage *Models can be translated and rotated *Depth-sorting so faces are rendered in the correct order *Screen-space culling - models that lie outside the screen coordinates are not processed, reducing render time *User can walk around with D-pad or analog stick and aim with touch-screen or gyro controls *Faces darken with distance, so models gradually fade into background *Radar on lower screen shows player position in relation to models *Code is reasonably well-documented *Sample scene included Planned features for the future: *Support for lighting *Scaling support for models *Actual gameplay features Known issues: *There is some distortion to the models when rotating on X and Y axis at the same time; I'm looking into it

Instructions:

Controls for Starblitz: D-Pad moves camera, Circle Pad moves ship Controls for FirstPerson: Circle-pad to move, touch-screen to aim, L or R to shoot Instructions for using the model editor: Load P3DModelEditor into Slot 0, and press Start. The model editor launches with a default cube model. The general idea is that you position points, called "vertices", and then connect them with triangles, called "faces". For example, a cube has 8 corners, so it has 8 vertices. Each side of a cube is a square, which requires two triangles to draw, so 12 faces in total. Controls: - A: Start moving vertex; confirm vertex position (Vertex mode). Confirm selected vertex (Add Face mode) - B: Cancel moving vertex (Vertex mode) - X: Select next vertex/face - Y: Select previous vertex/face - L: (hold) Increase movement speed (while moving vertex in Vertex mode) - R: (hold) Decrease movement speed (while moving vertex in Vertex mode) Touch screen controls should be mostly self-explanatory.
  • To create new vertices, press "Add Vert" while in Vertex mode.
  • To create new faces, press "Add Face". Select the first vertex and press "A". Repeat for two more vertices. When three have been selected, a new face (triangle) is created that connects the three selected vertices.
  • The RGB sliders can be used to edit the color of the selected face in Face mode. They have no effect in other modes.
Note: this engine is unrelated to the P3D engine; the "P3D" in "P3DModelEditor" is short for "Poly3D".

Notes:

Includes: - POLY3D.LIB: Engine library - GUILIB.LIB: Touchscreen GUI library - P3DMODELEDITOR: Model editor for Poly3D - STARBLITZ: simple example game, fly your ship and avoid crashing into obstacles
ProgramsToolsDevelopment ToolGraphicsTech Demo
12Me21#61
Replying to:Simeon
It's a bit difficult to control. but I can see this being really handy for 3D model making! The code is pretty straightforward, and well documented. Can you possibly add an export-to-text option, or a better way to access .3D/.3DM files? If I could have access to every triangle point, then this would be really convenient for me, and other developers here too! Thanks for making this!
.obj is extremely simple and widely used, so it might be worth adding a way to import/export files in this format.
kevinfoley#62
Replying to:Simeon
It's a bit difficult to control. but I can see this being really handy for 3D model making! The code is pretty straightforward, and well documented. Can you possibly add an export-to-text option, or a better way to access .3D/.3DM files? If I could have access to every triangle point, then this would be really convenient for me, and other developers here too! Thanks for making this!
Hmm, good suggestion. I think I could do an OBJ import/exporter without too much trouble.
kevinfoley#63
Replying to:Simeon
It's a bit difficult to control. but I can see this being really handy for 3D model making! The code is pretty straightforward, and well documented. Can you possibly add an export-to-text option, or a better way to access .3D/.3DM files? If I could have access to every triangle point, then this would be really convenient for me, and other developers here too! Thanks for making this!
@12Me21 Well, I wrote some simple code that could hopefully parse an OBJ file, but how would I get an OBJ file from my PC into SmileBASIC?
12Me21#64
Replying to:Simeon
It's a bit difficult to control. but I can see this being really handy for 3D model making! The code is pretty straightforward, and well documented. Can you possibly add an export-to-text option, or a better way to access .3D/.3DM files? If I could have access to every triangle point, then this would be really convenient for me, and other developers here too! Thanks for making this!
http://smilebasicsource.com/page?pid=812
rando#65
Replying to:Simeon
It's a bit difficult to control. but I can see this being really handy for 3D model making! The code is pretty straightforward, and well documented. Can you possibly add an export-to-text option, or a better way to access .3D/.3DM files? If I could have access to every triangle point, then this would be really convenient for me, and other developers here too! Thanks for making this!
lol yeah
kevinfoley#66
Replying to:Simeon
It's a bit difficult to control. but I can see this being really handy for 3D model making! The code is pretty straightforward, and well documented. Can you possibly add an export-to-text option, or a better way to access .3D/.3DM files? If I could have access to every triangle point, then this would be really convenient for me, and other developers here too! Thanks for making this!
I've released an update with general improvements and fixes to how axes/coordinates are handled, and a new demo game. The update also has the OBJ parsing code that I haven't tested. I'll need to copy a model file onto my 3DS using the modem app in order to try that.
DFrost#67
once this is like SANIC, you make is even faster by using sprites instead of GTRI, since you would be using sprites, it would be twice as fast when rendering a triangles. This also brings in textures to the mix. We might actually get an engine capable of running games like Crash Bandicoot(1996) at 30FPS Also I have noticed an exceptional difference of rendering speed when you constrain it all to the screen(s). Here is what I used(roughly): 
VAR M%,IT%
'draw IT% times because it is less noticable on small scale applications
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC - M%
GCLIP 0,0,399,239
M% = MILLISEC
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC-M%
if this doesn't produce usable results, just increase IT% this also takes care of off - screen culling, too. The culling only actually helps if a part of a triangle is on - screen. If not even a single pixel of a triangle is onscreen, the culling becomes ineffective. GCLIP actually is really useful in this scenario, but even SPCLIP and BGCLIP help, accordingly to what is being rendered.
kevinfoley#68
Replying to:DFrost
once this is like SANIC, you make is even faster by using sprites instead of GTRI, since you would be using sprites, it would be twice as fast when rendering a triangles. This also brings in textures to the mix. We might actually get an engine capable of running games like Crash Bandicoot(1996) at 30FPS Also I have noticed an exceptional difference of rendering speed when you constrain it all to the screen(s). Here is what I used(roughly): 
VAR M%,IT%
'draw IT% times because it is less noticable on small scale applications
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC - M%
GCLIP 0,0,399,239
M% = MILLISEC
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC-M%
if this doesn't produce usable results, just increase IT% this also takes care of off - screen culling, too. The culling only actually helps if a part of a triangle is on - screen. If not even a single pixel of a triangle is onscreen, the culling becomes ineffective. GCLIP actually is really useful in this scenario, but even SPCLIP and BGCLIP help, accordingly to what is being rendered.
I do not think rendering with sprites is practical. I already have a fast screen culling method in Poly3D. My culling method skips not only the drawing, but also many of the 3D calculations. Maybe I'm just not following you, but I don't see how your example code would help.
kevinfoley#69
Replying to:DFrost
once this is like SANIC, you make is even faster by using sprites instead of GTRI, since you would be using sprites, it would be twice as fast when rendering a triangles. This also brings in textures to the mix. We might actually get an engine capable of running games like Crash Bandicoot(1996) at 30FPS Also I have noticed an exceptional difference of rendering speed when you constrain it all to the screen(s). Here is what I used(roughly): 
VAR M%,IT%
'draw IT% times because it is less noticable on small scale applications
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC - M%
GCLIP 0,0,399,239
M% = MILLISEC
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC-M%
if this doesn't produce usable results, just increase IT% this also takes care of off - screen culling, too. The culling only actually helps if a part of a triangle is on - screen. If not even a single pixel of a triangle is onscreen, the culling becomes ineffective. GCLIP actually is really useful in this scenario, but even SPCLIP and BGCLIP help, accordingly to what is being rendered.
As far as I can tell, the Givers P3D game only uses triangle sprites for rendering the intro animation, and the result is an ugly mess of misaligned sprites. The rest of the gameplay seems to use flat-colored faces probably drawn with graphics commands. If you think you can make a 3D engine with sprites, go ahead, but I personally have no interest in trying to rewrite my engine to use sprites.
DFrost#70
Replying to:DFrost
once this is like SANIC, you make is even faster by using sprites instead of GTRI, since you would be using sprites, it would be twice as fast when rendering a triangles. This also brings in textures to the mix. We might actually get an engine capable of running games like Crash Bandicoot(1996) at 30FPS Also I have noticed an exceptional difference of rendering speed when you constrain it all to the screen(s). Here is what I used(roughly): 
VAR M%,IT%
'draw IT% times because it is less noticable on small scale applications
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC - M%
GCLIP 0,0,399,239
M% = MILLISEC
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC-M%
if this doesn't produce usable results, just increase IT% this also takes care of off - screen culling, too. The culling only actually helps if a part of a triangle is on - screen. If not even a single pixel of a triangle is onscreen, the culling becomes ineffective. GCLIP actually is really useful in this scenario, but even SPCLIP and BGCLIP help, accordingly to what is being rendered.
let's say we have a triangle that is partially off - screen. It would draw the rest of the triangle(offscreen) anyway. All I'm doing with this code is showing how GCLIP can improve performance by making it check "is this pixel I'm about to draw past the boundaries? Yes, so I can skip this one" this code proves sprites are faster to draw: 
VAR M%,I%
M% = MILLISEC
WHILE MILLISEC-M%<1001:GFILL I,0,15,15:INC I%:WEND
?"a moving box can be drawed",I%,"times a second"
I% = 0'reset it from our last test
SPSET 0,0'16x16 size
'since we are only [i]moving[/i] the sprite anddrawing it, don't include initialization of it.
M% = MILLISEC
WHILE MILLISEC - M%<1001: SPOFS 0,I%,0:INC I%:WEND
?"a moving sprite can be drawed",I%,"times a second"
DFrost#71
Replying to:DFrost
once this is like SANIC, you make is even faster by using sprites instead of GTRI, since you would be using sprites, it would be twice as fast when rendering a triangles. This also brings in textures to the mix. We might actually get an engine capable of running games like Crash Bandicoot(1996) at 30FPS Also I have noticed an exceptional difference of rendering speed when you constrain it all to the screen(s). Here is what I used(roughly): 
VAR M%,IT%
'draw IT% times because it is less noticable on small scale applications
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC - M%
GCLIP 0,0,399,239
M% = MILLISEC
FOR I = 1 TO IT%
GFILL 0,0,511,511
NEXT
?MILLISEC-M%
if this doesn't produce usable results, just increase IT% this also takes care of off - screen culling, too. The culling only actually helps if a part of a triangle is on - screen. If not even a single pixel of a triangle is onscreen, the culling becomes ineffective. GCLIP actually is really useful in this scenario, but even SPCLIP and BGCLIP help, accordingly to what is being rendered.
also, P3D has unaligned sprites because of the trashy way SB scales sprites. (you could add a wireframe rendition of each triangle as a cheap sprite anti-aliasing method.
Simeon#72
Sometimes triangles disappear when they are near-orthogonal to the camera. Your code currently draws the backfaces of models which means that when you have perspective and you sort, the back faces will sometimes be closer than the front when near-orthogonal to the camera. Adding this line of code will only draw one side of triangles, meaning the back faces will be skipped. It should also greatly boost your performance. Inside of the site's most up-to-date POLY3D.LIB file, consider adding the following to line 124 (maybe line 165 too). 
IF
((POINTS[E2,0]
-POINTS[E1,0])
*(POINTS[E3,1]
-POINTS[E1,1])
-(POINTS[E2,1]
-POINTS[E1,1])
*(POINTS[E3,0]
-POINTS[E1,0]))
>=0 THEN CONTINUE
The only issue is that this requires you to update all of your models, since there are inconsistencies in defining clockwise/counterclockwise triangles, so the models are a bit jumbled up, but only one side of them now gets drawn. I guess this also depends on how you want it to be, since your STARBLITZ demo (which is really awesome btw) has one-triangle-wide wings, which behaves wrong with this change. So, just consider it.
kevinfoley#73
Replying to:Simeon
Sometimes triangles disappear when they are near-orthogonal to the camera. Your code currently draws the backfaces of models which means that when you have perspective and you sort, the back faces will sometimes be closer than the front when near-orthogonal to the camera. Adding this line of code will only draw one side of triangles, meaning the back faces will be skipped. It should also greatly boost your performance. Inside of the site's most up-to-date POLY3D.LIB file, consider adding the following to line 124 (maybe line 165 too). 
IF
((POINTS[E2,0]
-POINTS[E1,0])
*(POINTS[E3,1]
-POINTS[E1,1])
-(POINTS[E2,1]
-POINTS[E1,1])
*(POINTS[E3,0]
-POINTS[E1,0]))
>=0 THEN CONTINUE
The only issue is that this requires you to update all of your models, since there are inconsistencies in defining clockwise/counterclockwise triangles, so the models are a bit jumbled up, but only one side of them now gets drawn. I guess this also depends on how you want it to be, since your STARBLITZ demo (which is really awesome btw) has one-triangle-wide wings, which behaves wrong with this change. So, just consider it.
I've never noticed triangles to disappear completely, but I'll keep an eye out for that. I thought about trying to incorporate normals for the purpose of backface culling and potentially lighting, but I didn't think it would be worth the tradeoffs and performance overhead. I like being able to use the two-sided triangles for flat details, like the wings that you mentioned. Another benefit is that you can make a line by connecting two of the three corners of a triangle to the same vertex, thus not requiring any extra code or edge cases to support lines. I've noticed that SIM.3D also has issues with occasionally drawing triangles out of order, causing similar flickering near corners. Thanks, I'm glad you enjoyed the STARBLITZ demo. I may expand it more after I add a few additional demos. Were you able to adapt the model editor for SIM.3D?
kevinfoley#74
I've added a simple first-person shooter demo where you can move around and shoot missiles at targets (it re-uses the models from the Starblitz demo). Real life has me pretty busy, but if I have time I'll eventually expand the demo into something a little fancier.
rando#75
I love the editor, but BUG: Basically one yellow triangle is not being rendered completely for some reason. It looks like a pink triangle is being rendered above it. (it's up to the right of another yellow triangles, the space between the 3 selected points should be yellow.) I also love the D-PAD precision. Thank you for not forcing me to use the circle pad :)
the_squat1115#76
Replying to:rando
I love the editor, but BUG: Basically one yellow triangle is not being rendered completely for some reason. It looks like a pink triangle is being rendered above it. (it's up to the right of another yellow triangles, the space between the 3 selected points should be yellow.) I also love the D-PAD precision. Thank you for not forcing me to use the circle pad :)
Did you know that the creator is no longer active? Just see his account.
rando#77
Replying to:rando
I love the editor, but BUG: Basically one yellow triangle is not being rendered completely for some reason. It looks like a pink triangle is being rendered above it. (it's up to the right of another yellow triangles, the space between the 3 selected points should be yellow.) I also love the D-PAD precision. Thank you for not forcing me to use the circle pad :)
Yeah I know. Posting bugs is still a good thing to do.
the_squat1115#78
Replying to:rando
I love the editor, but BUG: Basically one yellow triangle is not being rendered completely for some reason. It looks like a pink triangle is being rendered above it. (it's up to the right of another yellow triangles, the space between the 3 selected points should be yellow.) I also love the D-PAD precision. Thank you for not forcing me to use the circle pad :)
Ok...?
hakke#79
☆UwU☆ what's this? can i mwake fwortnwite thwee dee ess with this wondewful engwine OwO twanks pweaseeee oneesan UwU byeeeee!~★★★
IAmRalsei#80
Replying to:hakke
☆UwU☆ what's this? can i mwake fwortnwite thwee dee ess with this wondewful engwine OwO twanks pweaseeee oneesan UwU byeeeee!~★★★
i feel like stabbing you just for posting this
12345