The shoutbox is currently out of service. Join us on Discord instead.
You can help CodeWalrus stay online by donating here.

X3D - A 3D engine for TI68k & Nspire Calculators

Started by catastropher, June 27, 2015, 02:37:43 am

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DJ Omnimaga

Ah I see. On the HP Prime, all you have to do is copy the graphic buffer of your choice then display it on the screen at any size you want. Slowdowns occur with scaled graphics, but can be worked around quite easily. Keep in mind that HP PPL language is closer in style to TI-BASIC, though, and that that calc runs at 400 MHz.

And yeah I was glad that Lionel released GCC4TI, because back then the only TIGCC updates were for Windows Vista support and nothing new was added since 2006 or so. GCC4TI fixed that.

Lionel Debroux

Between TIGCC 0.96 Beta 8 in late October 2006, and the creation of GCC4TI, which was triggered in the summer of 2008 by thoroughly unrealistic development goals announced by the other Kevin, there were over 300 commits in TIGCC CVS, i.e. a bit more than a quarter of the TIGCC CVS history.
However, most of them were related to the KTIGCC (1 and 2) dead end. Among the dozens of commits to the toolchain and library between those dates, there are relatively minor features and bugfixes, but nothing of large impact, indeed.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

catastropher

Hi guys, sorry I've been gone for so long. I have, however, been working on X3D like crazy and am proud to announce four major changes to it since I last posted:

  • It's actually a library now, instead of a stand-alone executable

  • It can render in color (for color calculators/PC)

  • The code was rewritten to be platform-independent to facilitate porting to other devices

  • As of today, it can render wall portals, just like from the game Portal!!!


The last point is very very exciting, especially since I only go it to work today! It took me forever to figure out the matrix math haha Anyway, here is a demonstration of it running on PC (the red and green portals are connected):

X3D Portals: ShowHide




There are still several bugs to fix, and there are currently a number of limitations (you can't yet put portals on the ceiling or floor and you can't walk through them). These will be implemented soon though! :D
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Ohai nice to see you again Catastropher :3=

I like how X3D looks with the colored lines and black background. Portal support is definitively a nice feature :D. Would implementing portals on the floor slow the engine down?

Also for which platform is this screenshot from? I know the TI-84 Plus CE now supports C and has an emulator called CEmu. Keep up the good work :)

Ivoah

Ooooh, portals! Looks nice! How hard do you recon it'd be to port this to the Nspire? Or maybe even the GBA.

Lionel Debroux

Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

catastropher

Quote from: DJ Omnimaga on January 14, 2016, 05:48:51 pm
Ohai nice to see you again Catastropher :3=

Yeah, it's great to be back! I actually just graduated a few weeks ago (now I'm off to grad school!)

Quote from: DJ Omnimaga on January 14, 2016, 05:48:51 pm
I like how X3D looks with the colored lines and black background. Portal support is definitively a nice feature :D. Would implementing portals on the floor slow the engine down?

Thanks! And nope, it's the same speed to render, I just need to figure out the math of aligning the portal... in Portal, a portal casted on the ceiling or floor is rotated relative to the camera's rotation, so that's probably what I'll do.

Quote from: DJ Omnimaga on January 14, 2016, 05:48:51 pm
Also for which platform is this screenshot from? I know the TI-84 Plus CE now supports C and has an emulator called CEmu. Keep up the good work :)

This is from the PC, running at 320x240 (it can run at any resolution though). I wonder if the C compiler for the TI-84 Plus CE has the strange requirement of putting all variables at the beginning of functions (like SDCC). If so, I'm in for a lot of code reorganization :P

Quote from: Ivoah on January 14, 2016, 05:50:38 pm
Ooooh, portals! Looks nice! How hard do you recon it'd be to port this to the Nspire? Or maybe even the GBA.

Thanks! It should be fairly simple, actually. The code is organized into two pieces: the engine core, and the platform-dependent part. Every port of the engine has to implement a common interface (functions for e.g. clearing the screen, drawing the lines, reading which keys are pressed, etc). The renderer is very very fast (it can run on the 12 MHz 68k calculators) so it should be runnable on most platforms.

Quote from: Lionel Debroux on January 14, 2016, 07:13:48 pm
Looks pretty nice, indeed :)

Thanks! I really appreciate the encouragement! It's come a long way since I started last February! :D
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

SiphonicSugar

I'm just trying to grab some inspiration. :P

catastropher

Quote from: SiphonicSugar on January 15, 2016, 12:40:38 am
Oh my god!  PORTALS!

Hehe yeah, my friend Jason and I are already talking about how we're going to implement a game of Portal with X3D :D The hope, of course, is that other people will become more interested in the engine as it progresses. Descent is also on the list of games to develop, but Portal will probably come first.
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Yeah my main concern about portals is I did not know if the floor could be used like a wall. For example, I doubt Portal could be done with Doom or Wolfeinstein engine. :P

Also do you plan to implement a gradient background like the idea I suggested a while ago?

I'm glad you graduated, by the way. Congrats. :)

Vogtinator

QuoteAs of today, it can render wall portals, just like from the game Portal!!!

Wow, that looks definitely impressive!
As I've done some 3D-related work in the past, I'd like to know how you did it.
The way I'd do it in a more "modern" 3D environment with textured polygons is the following:
1. Render view of player into FBO, use stencil buffer for the portal.
2. Keeping the stencil active, get the position of the player relative to the portal and apply it to the other one.
3. Using that as the camera, render the scene into the FBO. Objects between camera and portal have to be culled.
4. Blit FBO to screen.

Of course, while the single steps can be optimized, it's still a lot of work to do for a fairly slow CPU (not even GPU...),
So, how do you achive it in X3D with wireframe graphics? Especially, how are recursive portals rendered?

catastropher

Quote from: Vogtinator on January 15, 2016, 09:49:17 pm
QuoteAs of today, it can render wall portals, just like from the game Portal!!!

Wow, that looks definitely impressive!
As I've done some 3D-related work in the past, I'd like to know how you did it.
The way I'd do it in a more "modern" 3D environment with textured polygons is the following:
1. Render view of player into FBO, use stencil buffer for the portal.
2. Keeping the stencil active, get the position of the player relative to the portal and apply it to the other one.
3. Using that as the camera, render the scene into the FBO. Objects between camera and portal have to be culled.
4. Blit FBO to screen.

Of course, while the single steps can be optimized, it's still a lot of work to do for a fairly slow CPU (not even GPU...),
So, how do you achive it in X3D with wireframe graphics? Especially, how are recursive portals rendered?

Hey! Thanks for taking interest in the engine! Well, rendering is a bit complicated to explain as it doesn't fill any polygons, nor does it do any Z sorting. Unfortunately, I had to create my own algorithms for this, so I'll do my best to explain (I wish there was a better resource to point you to). To understand how the portals work, I first need to explain how X3D does rendering. First off, the level is constructed of interconnected prisms that share a face. Between the shared face is an implicit portal connecting them. Second, all geometry in X3D is convex - including the rooms (called "segments") and the portals. This lets us make a number of assumptions:

  • Walls in a segment can be drawn in any order

  • Every wall in a segment is convex

  • Every convex polygon can be split into two polylines, one on the left and one on the right. This means a 2D polygon can be represented as two arrays, holding the x_left and x_right coordinate of each scanline.


This is very important for clipping. Suppose we have a convex polygon that describes the region of the screen that is visible. If we represented the polygon as N lines, clipping a line L against the polygon would take 2N multiplications and N divisions. If we use the scanline approach though, we can do a binary search to clip the line (I can explain this more if you want), so each line takes O(log L) where L is the length of the line.

Of course, how do we get such a clipping region? When the renderer begins, the clipping region is set to the entire screen. When a portal is enountered (after being clipped against the near plane), a 2D clipping region is constructed for the portal. We don't necessarily want to keep the entire portal clipping region; we just want the part of it that's inside the parent clipping region. So, we need to calculate the intersection of the two, which can also be done with a binary search (intersection of two convex polygons is always a convex polygon).

Now, anything on the other side of the portal is clipped aginst this new clipping region. This already allows for "solid wireframe" - any lines that would break the illusion of being solid are clipped by the clipping region. Even better, the only "filled" polygons are the faces that have portals, and they are never actually filled.

I modified the engine to visualize the process that is happening for rendering. It proceedes as follows:

  • The geometry of the current segment is fully drawn without clipping. Then, each line is clipped against the current clipping region, one by one.

  • When a portal is encountered, the parent clipping region is shown (filled red), followed by a new clipping region for the portal (filled green).
  • Then, they are intersected (filled blue) and the renderer draws the segment on the other side using this new clipping region. For a "remote portal", a camera transformation has to happen (I can explain it if you want, it's just some matrix and vector math). Luckily, this can be partially precomputed and only requires one matrix multiplication, two rotations, and two dotproducts to adjust it.


X3D Rendering: ShowHide


I hope this helps a little bit. It took me a long time to come up with algorithm, but there you go, solid 3D rendering for low-power devices :) Please, feel free to ask me any questions you have! Oh, and you can always look at the source code/contribute if you ever want to! The repository is here: https://github.com/catastropher/X3D-68k, though the code is a bit messy atm haha
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

I don't understand 3D but looking at this screenshot, I like visualizing how the 3D is rendered line by line :) . Also good move to make such screenshot after explaining, since some people are more visual and understand better with animations and pictures. :)

Vogtinator

Quoteas it doesn't fill any polygons, nor does it do any Z sorting.

Does that mean that "freestanding" polygons aren't possible with X3D?

QuoteEvery convex polygon can be split into two polylines, one on the left and one on the right. This means a 2D polygon can be represented as two arrays, holding the x_left and x_right coordinate of each scanline.

Hm, doesn't that mean that you convert back and forth between a array of points and an array of scanlines?

QuoteFor a "remote portal", a camera transformation has to happen (I can explain it if you want, it's just some matrix and vector math). Luckily, this can be partially precomputed and only requires one matrix multiplication, two rotations, and two dotproducts to adjust it.

Why two rotations and dotproducts? As I see that you're basically copying the room the target portal is in behind the view portal, isn't one rotation and one translation enough,
so one matrix multiplication/rotation and one addition/translation?

QuotePlease, feel free to ask me any questions you have!

How are matrices implemented? Using proper 32-bit floats, 32-bit fixed-point or entirely different?

QuoteI hope this helps a little bit.

Yep, it does! Thanks :)

ben_g

Quote from: catastropher on January 17, 2016, 12:29:56 am
X3D Rendering: ShowHide


From your explanation, I think you always clip against a polygon defined as a set of vertices, right? While this probably is no problem at all for computers and more powerfull calculators, I wonder if filling that polygon on a seperate 'clipping' buffer and then drawing lines using a modified OR-logic could speed the engine up on z80 calculators, especially if you limit all portals to squares, since the calculations required for clipping tend to be quite slow on that platform.

Since drawing filled polygons is also quite slow on that platform, it may be a stupid idea though.

Powered by EzPortal