Voxels

Community Forums/Monkey2 Talk/Voxels

GW_(Posted 2016) [#1]
Real voxels!, not texturemapped cubes that kids call voxels. Running at a blazing 9 fps!


download exe and source
Use a,s,d,w to fly around


A few of the WTF's I encountered
'Then' is an invalid token??!!
without '()' a method or function never gets called...
pixmap.convert crashes
sin,cos uses radian now?!
fps() as a function seems to never get called, but as a method it gets called
90 fps in Bmax



Leo Santos(Posted 2016) [#2]
Really cool! Compiled fine in OS X without those extra dll's.
Quick question: what's the difference between an Image and a Pixmap?

Thanks!
Leo.


GW_(Posted 2016) [#3]
A pixmap is just a block of memory holding the colors of an image in main memory. When loading a texture in opengl or directx, the pixmap gets converted into a texture and moved to the video card memory


Leo Santos(Posted 2016) [#4]
Thanks for the answer!
By the way, I was getting 9 or 10fps as well on my laptop, but as soon as I switched from Debug to Release, now I get 60fps and it's not even using 100% CPU!
:-D

I was testing it in Mollusk IDE, but it seems that the "debug" checkbox doesn't do anything, it's always compiled to debug mode. Doing it from Ted worked, though, and it's a massive performance improvement.

Cheers!


impixi(Posted 2016) [#5]
@GW_

Nice. Release build, I see 60fps on my 2015 iMac.

What tool did you use to generate the height map and colour map?


GW_(Posted 2016) [#6]
I wrote it and built it in Monk, in release mode I get 9 fps, in debug I get 2.
Strange, maybe having an integrated graphics card with shared memory makes things faster.. I have a gtx970.
I didn't create the images, they're from a 90's voxel helicopter sim called Commanche.


CopperCircle(Posted 2016) [#7]
Nice, I get 13 fps on my i7 with GTX760


therevills(Posted 2016) [#8]
I get 2 FPS in debug mode and 8 FPS in release mode running on a GTX670....


impixi(Posted 2016) [#9]
I just tried it on a PC that has an AMD Radeon HD 7970 card and it only ran at 12fps. There's obviously something amiss. A total guess is that on Windows OS, SDL2 is falling back to the software renderer. In SDL2 there is a function and associated structure to check for such things but it looks as if Mark hasn't exposed it for some reason.

@GW_
I remember that game. It was good in it's day... Something with a similar but updated style might do well in a VR setting perhaps? Regarding the heightmaps and related colour maps: I've coded procedural generators for such things in various languages, some years ago. Forgot all about that - might have to port some of it to Monkey2 as a side project...


impixi(Posted 2016) [#10]
@GW_
It must be something specific in your commanche code that's highlighting the performance discrepancy because I added a FPS counter to the mojotest.monkey2 "banana" and tried it on MacOS and Windows 10 and they both perform at 60fps...


GW_(Posted 2016) [#11]
It was never going to be fast, There is no 'DrawPixmap' style function in mojo, because it's using GL(ES?) .
Every frame it writes to a pixmap and casts it into an image:
canvas.DrawRect(0,0,WIDTH * 2, HEIGHT * 2,New Image(thePixmap))

That's why it's slow. It is odd that some people get good frame-rates though.
Doing the same thing with GL with a textured mesh would run at over 1000 fps.


impixi(Posted 2016) [#12]
It's interesting. I modified your code to render direct to an image so as to eliminate the need for New Image objects every frame and it actually performs worse. Down to 50 fps on my Mac. 7 fps on my PC and nothing is visible on that platform. But I guess Mojo is still in early release so we can't expect too much...

Here's the modified code (there's only minimal changes. And I have NO idea why only a black screen is visible on the PC. On Mac it displays as expected.)



EDIT: The primary changes are in LoadMap, OnRender, and Raycast


GW_(Posted 2016) [#13]
Yeah, Plotting will definitly be slower.
With my version, i'm uploading a texture and 4 verts to the graphics card every frame, and with a plotting method it's sending 131072 verts to the gfx card every frame along with a color change for each one.
btw: voxel rendering like this is an antiquated technique and not really suitable to modern graphics. The speed issue is not really related to M2.
It's just a bit of nostalgia as my first monkey2 program.


marksibly(Posted 2016) [#14]
Cool, some code to play with!

> 'Then' is an invalid token??!!

Shouldn't be, will inverstigate.

> without '()' a method or function never gets called...

Nope. It should be generating an error if you do this accidentally but that appears to be a bit bugged right now.

> sin,cos uses radian now?!

Yes. This is what FPUs (and 99% of other languages) use and (like color values from 0...1) it's something I think people will just have to get used to.

> fps() as a function seems to never get called, but as a method it gets called

Weird, will investigate.

> 90 fps in Bmax

Yep, that's strange.

Each new generation of GPU's gets more and more hostile to 'direct rendering' (which is always the first thing people seem to try with a new brl language!) but even then there seems to be something odd going on. I disabled all the rendering stuff in the 'draw to image' version and it was still strangley slow. GetPixelARGB seems to be taking a long time for some reason, although looking through the code I'm not sure why. Could it be drawing way more than it should? Perhaps due to radians issue? Will investigate anyway!


marksibly(Posted 2016) [#15]
Also, Image/Texture will eventually get 'PastePixmap' and this will probably be fastest way to do non-gpu rendering, ie: Paste pixmap to image, then drawimage...


GW_(Posted 2016) [#16]
> 'Then' is an invalid token??!!
I should qualify that, "If cond then expr" is fine, but "if cond then <crlf>" is the problem

the methods that dont get called without '()' were ":void" btw

Could it be drawing way more than it should? Perhaps due to radians issue?

I didn't think of that, I converted the program from bmax. Also maybe <wild speculation> those with good framerates have integrated graphics with shared memory, so the pixmap copy to graphics memory is not taking a hit.

If you comment out the fps() method and replace (above the app class) with
Function Fps:Float()
    Global FPStime:Float, frameCounter:Float, frameTimer:Float, totalFrames:float
    frameCounter+= 1
    totalFrames+= 1
    If frameTimer < Millisecs()
	FPStime = frameCounter
	frameTimer = 1000 + Millisecs()
	frameCounter = 0  
    EndIf
    Return FPStime
End Function

Then it doesn't seem to work. I didn't look to hard as why.


Leo Santos(Posted 2016) [#17]
Also maybe <wild speculation> those with good framerates have integrated graphics with shared memory


Nope, AMD 2GB discreet GPU here. The difference is the OS. I just booted in Windows 10, and I get 12 fps in Release mode. Back to OS X El Capitan, I get a solid 60fps, on the same computer. Drivers in Windows are updated (Fallout 4 and other games run great!), so I don't think it's that.

Also, disabling Pixmap operations renders a black screen but the fps seems to remain unchanged, the slowness in Windows seems to come from the Raycasting loop itself.

Cheers!


Richard Betson(Posted 2016) [#18]
Pretty cool.

I get 40 FPS (in release mode) on Linux Mint 17.3 (proprietary drivers) using a Radeon HD5770 (old card and on the way out of my system) with a Phenom II 3.8ghz quad core. The results seem to pair up with OS X which kind of makes sense. On Linux Mint 17.2 using the open source drivers I get 26 FPS.


marksibly(Posted 2016) [#19]
> The difference is the OS.

Yep, same thing happening here - fast on mac with ok-ish HW, fast-ish on linux with crap HW, but SLOW on pc with fast-ish HW.

My guess is mingw's optimizer is doing something weird (worse than bmx though?!?) - will look into it.


Richard Betson(Posted 2016) [#20]
Looks like there is a memory leak somewhere. Just sitting still when the demo runs it will slowly start consuming memory then picks up more steam as time goes on.


marksibly(Posted 2016) [#21]
Ok, I've found the problem - it appears to be a big nasty bug in mingw which seems to be adding extra 'mystery' code to some functions when the optimizer is enabled.

Changing the -O3's in bin/windows_env.txt to -Os results in much faster code (it shouldn't really). It's almost running at 60fps here now.

This is a pretty serious issue which probably even affects mx1 apps, and I've posted a bug report but I doubt anything's gonna happen for a looooong time so -Os is the solution for now.

Support for msvc and hopefully clang will happen eventually too, but after V1.0.

> Looks like there is a memory leak somewhere.

That's 'coz it's creating a new texture every frame - surprised it lasts as long as it does!


taumel(Posted 2016) [#22]
Both, degrees and radians, have their fields of application. In almost 28.32% of the cases this means: pos = amp * sin(ang * d2r).