• nGL - a fast (enough) 3D engine for the nspire 5 4
Currently:  

Author Topic: nGL - a fast (enough) 3D engine for the nspire  (Read 115827 times)

0 Members and 1 Guest are viewing this topic.

Offline ben_g

  • Hey cool I can set a custom title now :)
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1002
  • Rating: +125/-4
  • Asm noob
    • View Profile
    • Our programmer's team: GameCommandoSquad
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #75 on: February 19, 2014, 04:30:24 pm »
I think it's best to use the fastest version. The artifacts are not that visible and the graphics are amazing either way considering this is a calc game.
My projects
 - The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
 - Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
 - An android version of oxo (java)  ACTIVE
 - A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
 - A java MORPG. (pc) DEEP COMA(read more)(screenshot)
 - a minecraft game in axe DEAD (source code available)
 - a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated

Offline Vogtinator

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1192
  • Rating: +108/-5
  • Instruction counter
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #76 on: February 19, 2014, 04:35:54 pm »
Here's a version where the miscalculations are more clearly visible:
If it's further away the depth resolution decreases, in this .gif it's moving away with CONSTANT speed, so
the small "breaks" in movement are just differences beyond the precision.

Offline ben_g

  • Hey cool I can set a custom title now :)
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1002
  • Rating: +125/-4
  • Asm noob
    • View Profile
    • Our programmer's team: GameCommandoSquad
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #77 on: February 19, 2014, 04:46:08 pm »
Correct me if I'm wrong, but it looks like it starts happening at a reasonably large distance. You can make a decision based on the following statements:
 - Will the finished game have a view distance big enough for the artifacts to be visible?
 - Will the environment be very open so that there are nearly no nearby structures covering the ones further away?
 - Do you have enough leftover speed to switch to the more accurate version and program in the other things you want?
And if it's not hard to do, maybe you can make it an option, kinda like the fast/fancy graphics option of Minecraft.
But personally, I don't find it too disturbing. Many older games relied heavily on LOD's, which gave comparable artifacts when moving at a significant speed.
My projects
 - The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
 - Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
 - An android version of oxo (java)  ACTIVE
 - A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
 - A java MORPG. (pc) DEEP COMA(read more)(screenshot)
 - a minecraft game in axe DEAD (source code available)
 - a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated

Offline Vogtinator

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1192
  • Rating: +108/-5
  • Instruction counter
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #78 on: February 22, 2014, 07:03:53 pm »
It's weekend again, so some more progress:
  • Replaced terrain.png with original terrain.png from Minecraft (Copyright Mojang AB)
  • Trees
  • Infinite world generation (The trees are the only thing changing for now)
  • Faster startup (cos uses sin_lut)
  • Faster

With textures it's smooth now also with some more blocks visible (~25 fps):


I had to use imgur for that one as I couldn't upload it to img.ourl.ca.
The file was probably too large and every file I try to upload now (name doesn't matter)
doesn't get uploaded and it shows "crafti_world.gif" (the old file name!) was uploaded successfully and a 404 NOT FOUND next to it...

Without textures we can expand the viewable distance a bit further and we get to ~11 fps:


But for comparision fps-wise with the same distance as with textures above (~40 fps):


Known bugs:
-Weird lines if textures enabled
-Sometimes a triangle hitting the right screen border shows random data if textures enabled
-Sometimes it displays garbage if perfectly aligned to Z axis

Offline ben_g

  • Hey cool I can set a custom title now :)
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1002
  • Rating: +125/-4
  • Asm noob
    • View Profile
    • Our programmer's team: GameCommandoSquad
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #79 on: February 22, 2014, 07:20:48 pm »
The weird lines on the texture-enabled screenshot seems to be the result of inaccuracies when calculating the texel that belongs to a pixel, which causes it to read texels outside of the texture on the edges of triangles.
I assume that you're using 16*16 textures, right? Then make sure that the u and v coordinates never go above 15 (set them to 15 when they reach 16), or below 0 (only when they are signed), before doing the texel lookup and it should be fixed.
My projects
 - The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
 - Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
 - An android version of oxo (java)  ACTIVE
 - A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
 - A java MORPG. (pc) DEEP COMA(read more)(screenshot)
 - a minecraft game in axe DEAD (source code available)
 - a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated

Offline Vogtinator

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1192
  • Rating: +108/-5
  • Instruction counter
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #80 on: February 22, 2014, 07:24:57 pm »
I know where the lines are coming from and it's not exactly that.
It's a bit harder to fix though, because simply testing the coordinates EVERY PIXEL would be to slow.
But I kind-of know what I can do in this case.

Offline ben_g

  • Hey cool I can set a custom title now :)
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1002
  • Rating: +125/-4
  • Asm noob
    • View Profile
    • Our programmer's team: GameCommandoSquad
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #81 on: February 22, 2014, 07:28:29 pm »
You are using fixed-points, right? Well, then you can kinda cheat a bit by setting the coordinates to e.g. 0.1 and 15.9 instead of 0 and 16. It's just as fast as the previous code, but after experimenting a bit with the values, you can get rid of the lines witouth visuall distorting the texture.
My projects
 - The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
 - Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
 - An android version of oxo (java)  ACTIVE
 - A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
 - A java MORPG. (pc) DEEP COMA(read more)(screenshot)
 - a minecraft game in axe DEAD (source code available)
 - a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated

Offline fb39ca4

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1749
  • Rating: +60/-3
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #82 on: February 23, 2014, 12:51:49 am »
Since these textures are repeated, it would actually make more sense to wrap the texture coordinates. It would have to be tested per-pixel, however it should be fairly fast (as long as textures are a power of two size), just a bitwise AND on each coordinate value. For a minecraft engine, this would also open up the ability to simplify meshes in large, flat areas of the same block.
« Last Edit: February 23, 2014, 12:52:22 am by fb39ca4 »

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #83 on: February 23, 2014, 03:58:31 am »
I tried to fix the depth issues and had to use floats (or int_fast64_t which is equally slow to divide somehow) which is slower (depends on vertex count)
Which version is better? Or should I keep both?

I'd say go for the fastest. It' only disturbing when blocks are really far.

And nice progress :D
I'd say that you should include both mode (with and without textures) in the final version so that we can make beautiful screenshots with textures and build quickly too ;)
(not that it is slow with textures, but it is faster without so if we want to make quick changes, we might want a quick way).
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline Vogtinator

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1192
  • Rating: +108/-5
  • Instruction counter
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #84 on: February 23, 2014, 06:18:16 am »
Quote
You are using fixed-points, right? Well, then you can kinda cheat a bit by setting the coordinates to e.g. 0.1 and 15.9 instead of 0 and 16. It's just as fast as the previous code, but after experimenting a bit with the values, you can get rid of the lines witouth visuall distorting the texture.
I'm doing that already. I have a nice SAFE_MODE #define which tells me if something is read out-of-bounds and it was triggered with OpenGL like texture coords (0 - 1 on the edges) vs. nGL coords (0-1 - 1px on the edge pixels). As the lines are a unique color (for each texture) I don't think it's some out-of-bounds read (texture atlas, see below).

Quote
Since these textures are repeated, it would actually make more sense to wrap the texture coordinates. It would have to be tested per-pixel, however it should be fairly fast (as long as textures are a power of two size), just a bitwise AND on each coordinate value. For a minecraft engine, this would also open up the ability to simplify meshes in large, flat areas of the same block.
The problem here is that I'm using a texture atlas.
As I preprocess every Chunk and basically just have to iterate over a array of vertices, I'd have to determine which texture to bind for every triangle.
That'd be horribly slow.
The problem is rather a rounding issue, as with fixed-point x / y = z can be true, but z * y = x doesn't have to be.
Or maybe I'm just completely wrong. Who knows. I'll have to fix those bugs anyway...

Quote
I'd say go for the fastest. It' only disturbing when blocks are really far.
Actually, with the improved indexed-rendering I'd have to do less floating-point calculations so it's not that slow.
Still 18 fps if textures enabled.

BTW: Who told me that floats wouldn't be much slower than fixed-point? It was you, Levak, wasn't it?


Quote
I'd say that you should include both mode (with and without textures) in the final version so that we can make beautiful screenshots with textures and build quickly too
(not that it is slow with textures, but it is faster without so if we want to make quick changes, we might want a quick way).
That'd mean switching without recompiling, the problem here is that I enable and disable textures by #define ing TEXTURE_SUPPORT
and an if EVERY PIXEL would be horribly slow. So:
- Code duplication (Copy nglDrawTriangle)
- Ugly preprocessor usage: Move nglDrawTriangle into a header file and #include it with various #define s.


Offline fb39ca4

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1749
  • Rating: +60/-3
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #85 on: February 23, 2014, 12:51:10 pm »
Quote
Since these textures are repeated, it would actually make more sense to wrap the texture coordinates. It would have to be tested per-pixel, however it should be fairly fast (as long as textures are a power of two size), just a bitwise AND on each coordinate value. For a minecraft engine, this would also open up the ability to simplify meshes in large, flat areas of the same block.
The problem here is that I'm using a texture atlas.
As I preprocess every Chunk and basically just have to iterate over a array of vertices, I'd have to determine which texture to bind for every triangle.
That'd be horribly slow.
The problem is rather a rounding issue, as with fixed-point x / y = z can be true, but z * y = x doesn't have to be.
Or maybe I'm just completely wrong. Who knows. I'll have to fix those bugs anyway...
Why not do it like array textures in OpenGL?

Offline Vogtinator

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1192
  • Rating: +108/-5
  • Instruction counter
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #86 on: February 23, 2014, 12:55:29 pm »
Why should I?

Offline fb39ca4

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1749
  • Rating: +60/-3
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #87 on: February 23, 2014, 03:14:38 pm »
It avoids all the problems of texture atlases while still being a fast way to access multiple textures. You bind to one texture, and then because the format and size of the different textures in the array are the same, you only need to select the appropriate location for the texture data, which can be done by storing an integer ID with every triangle. All the pixels from one texture will be together, increasing cache coherency as well.
« Last Edit: February 23, 2014, 03:15:34 pm by fb39ca4 »

Offline Vogtinator

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1192
  • Rating: +108/-5
  • Instruction counter
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #88 on: February 23, 2014, 03:50:17 pm »
Quote
It avoids all the problems of texture atlases
Which problems? Without texture atlasses I would have the same problems as I have no.

Quote
You bind to one texture, and then because the format and size of the different textures in the array are the same, you only need to select the appropriate location for the texture data, which can be done by storing an integer ID with every triangle.
That's the problem. I'd have to switch the texture (even if it's just a id or pointer) every triangle and ALSO have UV-coordinates.
Of course it's nicer from the application's point of view.

Quote
All the pixels from one texture will be together, increasing cache coherency as well.
What about texture atlasses?

Edit: I built a quick hack into the engine:

The remaining artifacts are a mixture of inaccuracies and rounding errors.
« Last Edit: February 23, 2014, 04:21:28 pm by Vogtinator »

Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3820
  • Rating: +80/-8
    • View Profile
Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #89 on: February 23, 2014, 04:26:00 pm »
Wow that looks awesome O.O
send it