3D Rendering API (Has been released!)

The update is here:

http://www.computerc...48-3d-renderer/


Hey everyone! I've been working on an update to my old 3D renderer (I've rewritten a lot of the code):
http://www.computercraft.info/forums2/index.php?/topic/26848-3d-renderer/

The 3D rendering API will be suitable for certain games (including Mario Kart which I'm planning to make after this). I do not have any knowledge about how 3D rendering software works and I have not looked up a single thing. Be carefull when looking at my source code to learn how 3D rendering works.

Improvements:
- [DONE] It's using a buffer now so there's no flickering. (The buffer will be downloadable seperately so you can use if for other programs)
- [DONE] You can create your own models which are loaded using the API.
- [DONE] The faces are actually filled in.
- [DONE] Square objects look square on screen because the not-square pixels have been compensated for.
- [DONE] The orientation of objects are now changeable.
- [DONE] Objects are not rendered when they are not in sight.
- [DONE] Sky and ground colors are easily changed as background.
- [DONE] Change sorting algorithm to use table.sort() for a better performance.
- [DONE] Add support for use of Bomb Bloke's Blittle API.
- [DONE] Render distance is changeable.
- [DONE] Buf fix: rendering is messed up when looking down from above or up from below.
- [TO DO] Only render polygons when they're facing towards you for better performance Might not come within the next update. (Not sure yet)
- [DONE] Use term.blit() to draw the buffer in stead of writing char by char for better performance.
- [DONE] Clean the code!

I'll upload a video about it on my channel:
https://www.youtube....WJrIUyKtiYGeWxw

Here's a low quality GIF to keep you satisfied for now =D


I've been working hard. Here's a new GIF:

Now with improved FPS (GIF is 30 FPS max so it's only 3 seconds long):



The use of BLittle is now toggleable while running the program:

Do you have any thoughts how you could make the performance of this renderer better than the others who are veeery laggy? I WANT Mario CCart! :D/>

Jummit, on 27 August 2017 - 04:48 PM said:

Do you have any thoughts how you could make the performance of this renderer better than the others who are veeery laggy? I WANT Mario CCart! :D/>

What do you mean with the performance?
I don't see any problems with it at the moment.
The FPS is determined by how fast the "w" key is pressed (or any for that matter), but if you hold a key down, the speed of the events being triggered is the limiting factor. There's probably a way to double the FPS by acting as if it is pressed half-way through if it has been pressed without being released. (I haven't tried this yet)

Mario CCart is coming! :P/>

Btw, do you have any suggestions about other 3D games I could develop?

EDIT: About the FPS in this GIF: It's just the low GIF quality. It's better on video or on your screen if that was your question. (May have been over thinking that lol)

I like this game, but i think its way to complicated. But you could try to make something like this with airplanes/ships, so you dont have these walking things with much animations going on… Its called freaking robocraft, so let's go!

Perhaps you'd like to try running it through one of blittle.createWindow()'s buffers?

Jummit, on 27 August 2017 - 08:52 PM said:

I like this game, but i think its way to complicated. But you could try to make something like this with airplanes/ships, so you dont have these walking things with much animations going on… Its called freaking robocraft, so let's go!

That seems cool! However I don't know wheather a CC PC could handle it… I could tru something with more simple designs like TerraTech, though. The physics will not be easy lol. I'll see what I can do :D/>

Bomb Bloke, on 28 August 2017 - 03:29 AM said:

Perhaps you'd like to try running it through one of blittle.createWindow()'s buffers?

Oh. That would be awesome if it worked! I just don't exactly understand how to use it though. :P/>
Is it a buffer itself? If so, does it have functions for drawing triangles (given three coordinates)?
If not, can I feen my buffer into it every frame? Do I have to act as if the screen was 6 times bigger and then shrink the buffer with your API?

I can't see any screenshots in that post. It's not working. I'd like to get a simple example.
My buffer consists of a 2 dimentional array for x and y.
For example:

local pixelinformation = buffer[x][y]
local bgColor = pixelinformation.c1
local fgColor = pixelinformation.c2
local character = pixelinformation.char

Would it work with that?

EDIT/added:

Atm I have this function for drawing the buffer:

function drawBuffer()
  for x = 1, bufferX2 - bufferX1 + 1 do
    for y = 1, bufferY2 - bufferY1 + 1 do
      local pixel = screenBuffer[x][y]
      term.setCursorPos(x + bufferX1 - 1, y + bufferY1 - 1)
      term.setBackgroundColor(pixel.c1)
      term.setTextColor(pixel.c2)
      term.write(pixel.char)
    end
  end
end

It produces a buffer that's pretty similar to any regular terminal object, only you get "pixels" only - no "text". For a simple example, stick this at the top of your script:

os.loadAPI("blittle")
term.redirect( blittle.createWindow() )

So long as you aren't referring to term.native() or assuming your terminal's dimensions, you should get the effects automatically. The main catch will be that your pixels will become square, meaning your squashing code will become redundant.

While it's active, using the BLittle window's setVisible function is more efficient than delaying the draws through your own buffer (set the terminal invisible, draw the current frame, set the terminal visible again, and then repeat for each subsequent frame). I'd still expect it to be slower than what you're used to, though, due to the additional calculations involved in "shrinking" the pixels.

When you're not using BLittle, it's still worth bearing in mind that advanced computers typically offer a term.current().setVisible() too (as multishell uses windows for everything anyway) - using that would redraw a fair bit faster than the drawBuffer() function you're showing there, as it blits entire lines at a time. You might be able to get even better performance by directly implementing term.blit() within your own code, though.

Thanks for the help!
I tried it but I get an error when I try

term.setVisable(true)

"attempt to call nil"
Whenever I put the code at the top of my bufferAPI file, the program closes without any error and it only makes the cursor jump to the position (1 / 3 * screenWidth, 1) for some reason

Any ideas?

EDIT:

Nevermin about the first error. I edited the wrong file. Now it does the same as I described about the cursor position changing.

Really can't comment on your cursor-jump-and-exit without seeing the code in concern. If you don't want to publicise it yet, remember you can PM me.

Sure. I'll PM you.

Java gives an error when I use recursive functions. Therefore, I'm going to use insertionsort instead of quicksort for sorting the objects and vectors.

EDIT: I got the sorting done with table.sort()
Special thanks to Bomb Bloke!

Here's a pineapple by supernicejohn's signature request :P/>
http://www.mediafire.com/view/cdo2r52tc5flya3/Pineapple.png

Okay. Using term.blit() the performance is much better!
Here's a GIF of 3 seconds with 30 FPS Max:
via Imgflip GIF Maker

Could you make some advanced 3d objects (if it is not that hard to design one) just to show what you can do with it?
Ideas:

• basic landscape
• Car (maybe without wheels)
• cylinder
• house

Surely I can do that. When I release the code for people to use, I'd like to have a small library of models they can use or play with.
Though I don't know how easy it'll be to have good physics so the landscape won't vary in height, really. I could make some objects that can be used to design a landscape like:

• a few tree models
• rocks and boulders
• a small pond
• bushes
• clouds

Although, this will take quite a bit of time unless I really don't use a lot of polygons, since I have to edit all coordinates foor all polygons my hand (which is quite a bit of work). Maybe someone is feeling like making a program for designing these models?

To anyone who's willing to do that:
PM me so I can send you the structure the model files need to work and a pre release of my 3D Rendering for testing.

You can now horizontally rotate models!

Jummit, on 27 August 2017 - 04:48 PM said:

Do you have any thoughts how you could make the performance of this renderer better than the others who are veeery laggy? I WANT Mario CCart! :D/>

Just noticed. What do you exactly mean by "the others"? Do you mean the previous versions of this 3D renderer, or the 3D rendering software of other people?

Xelostar, on 03 September 2017 - 10:00 AM said:

Jummit, on 27 August 2017 - 04:48 PM said:

Do you have any thoughts how you could make the performance of this renderer better than the others who are veeery laggy? I WANT Mario CCart! :D/>

Just noticed. What do you exactly mean by "the others"? Do you mean the previous versions of this 3D renderer, or the 3D rendering software of other people?

Yes, i meant you're previous renderer and this genius thing. You didn't know it? I thought it was your'e inspiration…

Jummit, on 04 September 2017 - 12:35 PM said:

Xelostar, on 03 September 2017 - 10:00 AM said:

Jummit, on 27 August 2017 - 04:48 PM said:

Do you have any thoughts how you could make the performance of this renderer better than the others who are veeery laggy? I WANT Mario CCart! :D/>

Just noticed. What do you exactly mean by "the others"? Do you mean the previous versions of this 3D renderer, or the 3D rendering software of other people?

Yes, i meant you're previous renderer and this genius thing. You didn't know it? I thought it was your'e inspiration…

I know about it now, but at the time I released v0.3 of my 3D renderer, I didn't know about it. Now I know I'm not the only one. Nitrogen Fingers has made a proof of concept too.

The use of BLittle is now toggleable while running the program:

Wow. That looks really good. Doesn't look quite as good as Yevano's (mainly because Yevano's had some awesome 3D renders - like Minecraft with the moveable camera and the mountains with the valleys), but I reckon it could be better because you're using blittle.

EDIT: I'm assuming you fixed the 'term.setVisable()' bug? I was gonna say, it's spelt 'term.setVisible()'. :P/>

Dave-ee Jones, on 15 September 2017 - 06:36 AM said:

Wow. That looks really good. Doesn't look quite as good as Yevano's (mainly because Yevano's had some awesome 3D renders - like Minecraft with the moveable camera and the mountains with the valleys), but I reckon it could be better because you're using blittle. EDIT: I'm assuming you fixed the 'term.setVisable()' bug? I was gonna say, it's spelt 'term.setVisible()'. :P/>/>

Thanks! As you can see, I'm not a professional, but I think it turned out quite well trying to reinvent the weel.

Of course I fixed that bug. Bomb Bloke pointed it out to me some time ago and I got BLittle working. However, I wanted it to work better and I wanted it to be switchable while the program is running.

I'm fairly certain Yevano's 3D renderer uses the BLittle API as well. I think Bomb Bloke helped him in the comment section of that topic. However, sadly the code isn't public, so noone can use it. I really want to see 3D games being made, but since there isn't a very good 3D library, I made my own.

The update is here!