Voxels
Community Forums/Monkey2 Talk/Voxels
| ||
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 |
| ||
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. |
| ||
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 |
| ||
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! |
| ||
@GW_ Nice. Release build, I see 60fps on my 2015 iMac. What tool did you use to generate the height map and colour map? |
| ||
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. |
| ||
Nice, I get 13 fps on my i7 with GTX760 |
| ||
I get 2 FPS in debug mode and 8 FPS in release mode running on a GTX670.... |
| ||
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... |
| ||
@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... |
| ||
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. |
| ||
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 |
| ||
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. |
| ||
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! |
| ||
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... |
| ||
> '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. |
| ||
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! |
| ||
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. |
| ||
> 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. |
| ||
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. |
| ||
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! |
| ||
Both, degrees and radians, have their fields of application. In almost 28.32% of the cases this means: pos = amp * sin(ang * d2r). |