Montag, 21. Januar 2019

Update - Situation not resolved (Beware the poisons Levofloxacin, Ciprofloxacin)


Some asked me if it got better - actually it got worse. After just 3 pills I can barely walk and got a nephrotic syndrome in addition.. Be aware of Fluoroquinolones and never take them !!



Btw, Fluoroquinolones are responsible for most antibiotic caused disabilities - but thats not what they tell you when you get the prescription. They say its well tolerated.

Brief addition: This blog uses Cookies for Google Analytics und AdSense. According to EU law, I need to state this on the page.


Mittwoch, 22. Juni 2016

Side effects of Antibiotics (Levofloxacin, Ciprofloxacin) forced me to put dev on hold

I got side effects of antibiotics (levofloxacin,ciprofloxacin) and am currently not able to continue the voxel development. Once it gets better I will resume.

Be warned: Those antibiotics have delayed severe, sometimes permanent, side effects and damage nerves, eyes, ears, tendons, heart, muscles, joints and bones. While you take the medicine everything is fine, but weeks later tendons, muscles and joints start to hurt so you can barely move. The package insert says it occurs 1:10000, but my doctor honestly said every 100th patient of him has issues with it.

You can help to make other ppl aware of this danger by sharing and signing this petition (German)

Main points are:

* Germany/better Europe should get a black box warning like US
* Restrict use to life-threatening situations
* Drugs to treat these side effects need to be researched
* Tests for testing adverse reactions from blood or DNA samples need to be developed

https://weact.campact.de/petitions/warnung-und-eingeschrankter-einsatz-fur-chinolone-antibiotika

http://www.fluorchinolone-forum.de/

Freitag, 8. April 2016

Planet Rendeing : Recursive Level of Detail, With Code

Today I present you a level of detail algorithm for planet rendering. It has merely 100 lines of C++.

https://github.com/sp4cerat/Planet-LOD






Samstag, 19. März 2016

Basic Networking

Basic Networking working. So far without any physics & voxels. Running server + 4 clients @60fps on my Notebook simultaneously.


Donnerstag, 25. Februar 2016

OutStar Demo (Pre-Akpha)

This is a pre-alpha of OutStar - Enjoy.






It contains three modes:

1. The game mode (no shooting so far, just walk around)
2. Block edit (toggle with tab)
3. Sculpt editor (toggle with middle mouse button)

Controls:

F1 Screenshot
F2 Toggle Fullscreen
F3 Game/Edit Mode
F4 Sculpt Mode
F5 Save Level
F6 Load Level
F7..F10 Set Resolution 1024x512..1920x1080

TAB Toggle Edit/Game Mode

Space Jump
wsad Move Player
Shift Run

Game Mode:

LMB : Will be shoot

Edit Mode:
LMB set block
MMB Toggle Sculpting Tool
RMB delete block
Wheel: change block

Hold the LMB/RMB and drag to set a larger area

In sculpting tool:
Add block to octree : adds a new block to the available list


Dienstag, 3. November 2015

Game-Net: Simple RPC System for Games (C++11)

Summary
The library provides basic client / server network functionalities for games using RPCs. The major strength of the library is the template based RPC class. It allows to register and call RPCs effortless. It further includes a tutorial game server and game client (each around 300 lines of code ) for a very simple multiplayer shooting game as a proof of concept.
Network RPC Lib Features
  • Register RPCs in one line. The RPC class autodetects all paramters from the function pointer
  • RPC Data-type mismatch or wrong number of parameters are stated as error to ease debugging
  • Numbers are automatically sent as the smallest possible datatype (byte, short , .. )
  • Supports GLM datatypes for use in 3D Games
  • Supported Datatypes : (u)char,(u)short,(u)int,float,double,vector,map, GLM vec,mat and quat
  • Support for nested Datatypes like map [ string , vector ]
  • Reliable and unreliable calls possible
  • Function pointers of remote functions are not required
  • Based on ENet
  • Tested on Cygwin, Linux (Ubuntu) and Windows
  • C++11 based
Network RPC Lib Limitations
  • RPCs cannot be class member functions
  • No compression
  • No encryption
  • Only void functions supported. Non-void functions were tested but complicated everything.
  • Client to Client connections are not supported
Example Game Features
  • Lobby
  • Multiple Games
  • Handle spwaning/removing of game objects
  • Simple Shooting functionality
  • Intentionally textmode for simplicity
Benchmark
A first simple test on localhost (Core i7 Notebook) gave:
1 Call / Network Update:
  • 69.000 unreliable RPC calls/sec [client.call_ex(0,"hello_server", "Greetings")]
  • 74.000 reliable RPC calls/sec [client.call_ex(1,"hello_server", "Greetings")]
10 Calls grouped / Network Update
  • 144.000 unreliable RPC calls/sec [client.call_ex(0,"hello_server", "Greetings")]
  • 310.000 reliable RPC calls/sec [client.call_ex(1,"hello_server", "Greetings")]
20 Calls grouped / Network Update
  • 142.000 unreliable RPC calls/sec [client.call_ex(0,"hello_server", "Greetings")]
  • 364.000 reliable RPC calls/sec [client.call_ex(1,"hello_server", "Greetings")]
Note that this is not about the response time
Example Usage
Call Server Function:
Client Side:
NetClient client;

void set_pos(vec3 pos)
{
    // do something
    exit(0);
}

int main()
{
    rpc_register_remote(client.get_rpc(), login);
    rpc_register_local(client.get_rpc(), set_pos);
    client.connect("localhost", 12345);
    client.call("login", "myname", "pass");
    while(1) client.process();
    //client.disconnect();
}
Server Side:
NetServer server;

void login(uint clientid, string name, string password)
{
    // clientid is the first parameter for server functions
    server.call(clientid, "set_pos", vec3(1,2,3));    
}

int main()
{
    rpc_register_local(server.get_rpc(), login);
    rpc_register_remote(server.get_rpc(), set_pos);    
    server.start();
    core_sleep(10000) ; // wait client to do stuff
    server.stop();
}

Dienstag, 28. Juli 2015

Github Code

I shifted some of my code to GITHUB. You can find it here https://github.com/sp4cerat

Mittwoch, 15. Juli 2015

OpenGL Game GUI / Widgets with Source Code (C++)

The GUI is intended for PC and/or Console Games. 
Focus was mostly on keeping everything simple, easy to use, fast, and flexible (like having skin and ttf support).
The performance is ~700 fps for 20 windows and 100 fps for 100 windows on a Notebook PC (NVidia GTX 765 / Core i7 2.4). 

The source (MIT license) can be downloaded from GitHUB or here



Usage examples:

Creating and opening a window: 

gui.window["mywin"]=Gui::Window("Hello World",100,100,350,250);

Adding a button:

gui.window["mywin"].button["Ok1"]=Gui::Button("OK",20,100,60,20);

Adding a callback to close the window when pushing the button:

gui.window["mywin"].button["Ok1"].callback_pressed=
  [](Gui::Window *w,Gui::Button* b,int index) { w->close(); };


Here two screenshots with different skins
( VS2012 / OpenGL / GLUT based / MIT license )

Features:
  • Advanced skin scaling: define how the inner and borders of a texture shall be scaled ( simple scale, repeating inner pattern or constant outer frame, carried out by 3 Shader types)
  • UTF8 Support
  • TTF Support
  • Easy skinning support
  • Alpha support (RGBA), so you can have transparent windows/widgets etc
  • direct access to all controls and their members
  • Non-blocking visualization
  • Callback support
  • Different from most GUIs, Widgets are stored directly inside the GUI rather having local variables pointing to instances of an overwritten class.
  • Directory: Controls are stored and accessed by a tree structure that is rendered every time like a scene graph
  • No event loop, show function or update function
  • No need to have a timer that calls an update function
  • Lightweight: Only Depends on GL and libFreetype and DevIL
  • Can easily be used in SDL, Qt and other environments. Just plug in the keyboard and mouse events and call the gui's draw function from your main render loop.
  • Config file support for default variables (font,padding etc) and skin textures+scaling parameters
  • Only 2000 lines of code for the entire Gui class including all widgets. Therefore easy to modify and extend.
  • Comes with a simple file-browser (See screenshot1)
  • MIT license
  • Multi-screen support (same as multiple Desktops). You can have a title screen, loading screen, ingame screen etc. Simply create them at the beginning and the switch between by setting gui.active_screen=number;
  • Window manager
  • Context menu
  • Custom mouse pointer
  • Controls have support for custom user variables like control.var.string["myvar"]="hello"
Available classes for controls:
  • Window class
  • Label class
  • Button class
  • Combo class
  • Radio class
  • Tab class
  • Textedit class
  • Slider class
  • CheckBox class
  • Menu class
What the GUI is good for:
  • PC/Console Games
  • Simple menus
What the GUI might not be suited for
  • Complex GUIs that need tree-views , docking ,drag & drop etc
  • Mobile Devices ; perhaps too slow (needs testing) and also the render code needs to become OpenGL ES
Current Limitations (might be solved in the future)
  • Uses old OpenGL (glMatrix etc)
  • Usually one or two render calls per widget rather than one opengl render call for the entire gui.
  • 2D windows/widgets only. You could overwrite the render shader to get 3D, but you would have to map 2D mouse coordinates to 3D then by yourself. 
  • No animations (you could create them yourself by updating the textures accordingly or modifying the shader that render the widgets)
  • Only one font size and one font type
  • The GUI class is a singleton
  • The TextEdit does not support arbitrary cursor position or ctrl+c/v/x operations
  • Drag and Drop is not supported
  • No automatic window layout
  • No docking
  • No Ressource files (yet)
  • No treeview class
  • No caching of rendered labels, geometry, etc. Therefore every frame, the entire tree is traversed and every single character of a rendered text is processed for rendering.
The usage is also described in the previous post.

The code used to create window + widgets + menu in screenshot2  is the following:

 gui.init( Gui::Flags::CONTEXT_MENU | Gui::Flags::CUSTOM_MOUSE ,
    "../data/gui_global.txt" , 
    "../data/gui_skin.txt");

 // Main Window

 Gui::Window w=Gui::Window("Hello World",100,100,350,250); 

 // Add Simple Label to Window

 w.label["l"]=Gui::Label("Label",20,70,100,20);

 // Add Simple Button to Window

 w.button["Ok1"]=Gui::Button("OK",20,100,60,20);
 w.button["Ok1"].callback_pressed=
  [](Gui::Window *window,Gui::Button* control,int index)
  {
   window->close();
  };

 w.button["Ok2"]=Gui::Button("",220,100,100,100);
 w.button["Ok2"].skin=Skin( "../data/smiley.png",
        "../data/smileybw.png",
        "../data/smiley2.png");

 // Add Simple Combo to Window

 w.combo ["cb"]=Gui::Combo(120,100,60,20);
 w.combo ["cb"].add_item("test");
 w.combo ["cb"].add_item(L"東京");
 w.combo ["cb"].callback_selected=
  [](Gui::Window *w,Gui::Button* control,int index) // text entered callback example
  {
   Gui::Combo &c=*(Gui::Combo*)control;
   w->label["l"].text=Gui::String( c.selected ) + "  selected";
   w->label["l"].textcolor=vec4f(1,0,0,1);
  };

 // Add Text Edit to Window

 w.textedit["txt"]=Gui::TextEdit(10,"text",20,150,160,20);
 w.textedit["txt"].callback_text_entered=  
  [](Gui::Window *w,Gui::Button* control,int index) // text entered callback example
  {
   Gui::TextEdit &t=*(Gui::TextEdit*)control;
   w->title.text=t.text;
  };

 // Add Radio

 w.radio["rad"]=Gui::Radio(20,190,20,20); // first button
 w.radio["rad"].add_item(50,190);   // second button
 w.radio["rad"].add_item(80,190);   // third button
 w.radio["rad"].callback_pressed=
  [](Gui::Window *w,Gui::Button* control,int index)
  { 
   w->x+=10;
  };

 // Add Slider

 w.slider["s1"]=Gui::Slider( 0,200,100,   /* min,max,default*/ 
        20,220,160,20); /* window x,y,sx,sy */ 
 w.slider["s1"].callback_pressed=
 [](Gui::Window *w,Gui::Button* control,int index)
 {
  Gui::Slider &b=*((Gui::Slider*) control); 
  w->button["Ok1"].text=Gui::String(int(b.val)); 
 };

 w.slider["s2"]=Gui::Slider( 0,200,100,   /* min,max,default*/ 
        350,100,20,160, /* window x,y,sx,sy */
        Gui::Slider::VERTICAL );

 // Add File Menu to Window

 Gui::Menu m=Gui::Menu("File",/* x,y,sx,sy */ 9,39,50,20, /* menuwidth */ 100);
 m.add_item("Load",
  [](Gui::Window *window,Gui::Button* control,int index) // menu button callback
  {
   gui.screen[0].window["filebrowser"]=  // open file dialog
    gui_file_dialog( "Load SaveGame" , "Load" , "Cancel" ,
     /*get_current_dir()*/ "..\\data\\win8",".png", 100,100,

     // file dialog ok button callback
     [](Gui::Window *w,Gui::Button* b,int index) 
     {  
      MessageBoxA(0, 
       w->textedit["Filename"].text.c_str() , 
       w->label["dir"].text.c_str() ,0);  
      w->close();    
     }
   );
  });

 m.add_item("Close",
  [](Gui::Window *w,Gui::Button* control,int index) // menu button callback
  {
   w->parent->close(); // close window
  });

 m.add_menu("submenu");
 m.window.menu[0].add_item("test1");
 m.window.menu[0].add_item("test2");

 w.menu["menu"]=m;

 // Add new Window to Screen 0 (default)

 gui.screen[0].window["hello1"]=w; // finally put window on the screen (1st copy)

 // Modify and Add new Window to Screen 0 (default)

 w.move(500,100);
 w.resize(400,300);
 w.minsize(150,150);

 gui.screen[0].window["hello2"]=w; // finally put window on the screen (2nd copy)

 // -------------------------------------------------------------------------

 // also use our previous menu as context menu and file menu
 // Note : "context_menu" is reserved for the context menu
 //    all other id names are common menus on the background

 gui.screen[0].menu["context_menu"]=m;

 gui.screen[0].menu["file"]=m;
 gui.screen[0].menu["file"].y=5;

 // -------------------------------------------------------------------------

 // Add Button to Background

 gui.dialog["sample"]=w; // store for later use in the callback

 gui.screen[0].button["more"]=Gui::Button("More Windows Plz!!",50,50,200,20);
 gui.screen[0].button["more"].callback_pressed=
  [](Gui::Window *w,Gui::Button* control,int index) // menu button callback
  {
   int id=gui.screen[0].window.add(gui.dialog["sample"]);
   gui.screen[0].window[id].x= timeGetTime() % (int)gui.screen_resolution_x;
   gui.screen[0].window[id].y= timeGetTime() % (int)gui.screen_resolution_y;
  };

 // Add Tabbed Window to Background

 Gui::Tab t=Gui::Tab("Win1",350,150,300,200,50,20);;
 t.add_tab("Win2");
 t.add_tab("Win3");
 t.add_tab("Win4");
 loopi(0,4)
 {
  t.window[i].button.add(Gui::Button("OK",20+i*10,20,60));
  t.window[i].label["lab"] =Gui::Label("some text",20+i*20,90,100);
  t.window[i].button["test2"]=Gui::Button("OK",100+i*10,20,60);
  t.window[i].button["test3"]=Gui::Button("OK",50+i*10,50,60);
 }
 t.flags=Gui::Tab::MOVABLE; // Make it movable
 gui.screen[0].tab["mytab"]=t;



Main reason for the development of the GUI was, that after trying several gui's more or less suited for games (LibRocket, Qt, NVWidgets, CEgui, etc), I found that none of them was really light weight, easy to use and fully skinable at the same time. So the solution was to create one which is exactly so. 




Mittwoch, 1. Juli 2015

OpenGL Game GUI & Widget Development (Alpha Demo)

Today I am going to share some progress on my GUI project.

The Design Goals were:
  • Simplicity : Create a control in one line
  • Easy Skinning support
  • TTF and UTF8 support
  • Directory : Controls can be accessed by a tree structure
  • Direct access of all data members like if a button is pressed e.g.
  • No Event Loop
  • Static non-blocking visualization
  • Dialog Templates from ressource text file
  • Callback support 

Some simple examples:
Creating a window: gui.window["idname"]=Gui::Window("Title",100,100,250,350);
Closing a window: gui.window.erase("idname");
Adding a button : gui.window["idname"].button["load"]=Gui::Button("Load",20,20,50,30);

Change the skin of a window or other control:
gui.window["idname"].skin=Skin("normal.png","hover.png","selected.png");

There is no need to create a variable for most cases. The GUI handles that for you. It will cover basic functions that a required in a game. Its not optimized for speed, yet fast enough in most cases.

You can fetch an alpha demo of the gui here : [ DOWNLOAD ]

I will post more details soon.




Mittwoch, 27. Mai 2015

Sparse Voxel Octree Raytracing based Occlusion Culling (Theory)

I will share some thoughts on how the next generation of block based sandbox games rendering (triangle based) and creators pipelines might look like. In current games, overdraw is the most limiting factor when drawing high detailed scenes - that means, occlusions are not determined 100% accurate. Further, it is necessary to traverse some data structures on the CPU to create a list of objects to be rendered on the screen.

To improve on this, here the proposal for a completely GPU based solution that uses octree raycasting to determine the visibility.


The first step is to raycast a low res, lets say 128x128 pixel, ID buffer, which takes about 1ms from experiments. This is fast and only used to determine the visibility. In a second step, we create a list of visible objects and further merge with the list of objects that were visible in the past few frames. The list is generated as input buffer for glmultidrawelementsindirect. The steps until now are performed on the GPU using multiple CL or GL compute kernels. The final step is to draw all object with one GL call. The raycasting and grouping of duplicate IDs on the screen can be performed best in opengl compute or opencl. To not miss out distant objects only occupying a few pixels, it is necessary to add jittering to the rays casted. The proposed technology will allow the use of high resolution blocks for sandbox games while the performance is high enough to run on notebooks at high frame rates.

The creation pipeline is as usual:


First, sculpting / creating of the mesh as hi-res, then creating LODs+Normal maps using mesh simplification and transferring the details to a normal map.

Actually, there is already a similar method out there for a while called instant OC. It is not that effeciently integrated however. Its a script addon to Unity - yet, is uses raycasts to determine the visibility (1000-2000 have been the demo settings). 

Donnerstag, 21. Mai 2015

Sparse Voxel Octree (SVO) Reprojection Raycast Tech-DEMO

I decided to release a tech demo of the sparse voxel octree raytracing re-projection algorithm. Feel free to download and try it out. It uses OpenCL and should run on NVIDIA in any case. For ATI and INTEL HD I cannot guarantee. You might further need VS2012 redistributables 32 bit.

Usage:

Mouse : Look around
w,s,a,d,q,e : Move around
Space : See the re-projected pixels (lower image)

The algorithm raycasts only a fraction of pixels for each screen. Most are re-used from the previous frame exploiting frame-to-frame coherency, which allows a speed up of up to 4x. The algorithm is explained in more detail in a previous post.





Sonntag, 12. April 2015

Work in Progress on Outstar (SSAO / Bugfixes)

After a year, I finally found time to continue the development. Here a shot from a castle I built in about 1 day, including sculpting of some new blocks. Note that there are also rooms behind windows where you can walk around inside The new version also has a lot of bugfixes and now is getting closer to be ready for a demo release. SSAO (the lowermost image) is in progress, but not yet to my satisfaction. The complete castle's octree ist stored in 2.1MB on Hard disk. Title of the game will be Outstar. You can soon check out http://www.outstar.net . (The 20 fps in the screenshots is because I captured them on my notebook rather desktop PC)










Donnerstag, 22. Mai 2014

Voxel Engine Update - 18 Level Octree & Copy Paste in Action

Copy and Paste works well now. Areas of voxels can be grouped to new entities for placing them in the scene. The size of the entire voxel data of the screenshot below on disk is just 1.3MB, which is quite OK. Thanks to my new graphics card, voxel raycasting and terrain rendering also runs smoothly at 60+ fps at full HD resolution now. Also worth a note: The raycasting method is updated to allow octrees greater than 16 levels - the scene below is created in an 18 level octree. Now, problems with precision begin to arise, which need to be solved.




Dienstag, 13. Mai 2014

Quadric Mesh Simplification with Source Code

In the past days I have written a quadric based mesh simplification program. After searching the internet I couldnt find any code that was free to use, not unnecessarily bloated, fast and memory efficient, even the quadric based method is soon 20 years old. I therefore decided to write one myself.

Features / Summary:
  • Threshold based, therefore faster than sorting based methods
  • Since the Quadric Matrices are symmetric, only 10 elements are stored & computed per Matrix instead of 16
  • Non-closed meshes are supported by extra treating mesh borders
  • Simplifies 2.000.000 triangles to 20.000 triangles in 3 seconds on a Core i7
  • MIT License
  • MS Visual Studio 2012 , C++
Update Sept.20th 2014 : improved quality of reduced borders

The result is short and easy to use in case you need to adopt it to your project. You can fetch the C++ Project with source here: (about 300 lines for the main part, contained in Simplify.h )

Download Source and Data

The code is about 4x-7x faster than Meshlab, which is already fast. Using multi-core programming, it could even be faster.

Here a comparison along Meshlab, QSlim and this method:


Program output (left) and Meshlab (right). Note that Meshlab produces floating teeth and looses details around the eyes, nose and the mouth region. Reduction was 85k -> 3k Triangles.


Original (left) this code (middle) and meshlab (right)


Here another comparison: Program output (left) and Meshlab (right).

Samstag, 3. Mai 2014

Raycaster Speed-Up up to 400% by Image Warping (ReProjection)

Introduction: Since real-time raytracing is getting faster like with the Brigade Raytracer e.g., I believe this technology can be an important contribution to this area, as it might bring raytracing one step closer to being usable for video games.

Algorithm: A technology I am working on since a while now is to exploit temporal coherence between two consecutive rendered images to speed up ray-casting. The idea is to store the x- y- and z-coordinate for each pixel in the scene in a coordinate-buffer and re-project it into the following screen using the differential view matrix. The resulting image will look as Fig.1.

The method then gathers empty 2x2 pixel blocks on the screen and stores them into an indexbuffer for raycasting the holes. Raycasting single pixels too inefficient. Small holes remaining after the hole-filling pass are closed by a simple image filter. To improve the overall quality, the method updates the screen in tiles (8x4) by raycasting an entire tile and overwriting the cache. Doing so, the entire cache is refreshed after 32 frames. Further, a triple buffer system is used. That means two image caches which are copied to alternately and one buffer that is written to. This is done since it often happens that a pixel is overwritten in one frame, but becomes visible already in the next frame. Therefore, before the hole filling starts, the two cache buffers are projected to the main image buffer.

Limitations: The method also comes with limitations of course. So the speed up depends on the motion in the scene obviously, and the method is only suitable for primary rays and pixel properties that remain constant over multiple frames, such as static ambient lighting. Further, during fast motions, the silhouettes of geometry close to the camera tends to loose precision and geometry in the background will not move as smooth as if the scene is fully raytraced each time. There, future work might include creating suitable image filters to avoid these effects.

Results: Most of the pixels can be re-used using this technology. As only a fraction of the original needs to be raycasted, the speed up is significant and up to 5x the original speed, depending on the scene (see Fig.2 - Fig.4). Resolution for that test was 1024x768, the GPU was an NVIDIA GeForce GTX765M.

Here also two videos showing this technology in action: Video1 Video2 
(I uploaded them a while ago)

Finally a few papers for further reading:
Exploiting Temporal Coherence in Ray Casted Walkthroughs
Iterative Image Warping
A Shared-Scene-Graph Image-Warping Architecture for VR: Low Latency versus Image Quality
Three-Dimensional Image Warping on Programmable Graphics Hardware
Accelerating Real-Time Shading with Reverse Reprojection Caching

Fig.1 Result after basic re-projection



Fig.2 Original Version

Fig.3 With Re-Projection Enabled + In Motion

Fig.4 With Re-Projection Enabled + Standing

Mittwoch, 30. April 2014

Polygon Rendering vs. Voxel Raycasting

Since I started the project I have always wondered if it wouldnt be better to use polygons/triangles rather than voxels. To verify this decision, I created a reasonably complex test scene from multiple instances of the same block, and rendered the scene once with triangles using Display Lists & LOD and second using voxel raycasting (LOD inherently). The triangle block is created by exporting the voxels as polygon mesh, and then using Meshlab to reduce the triangles and create multiple LOD levels.

It turns out that triangles are much faster for a small to a medium number of instances (its about equal for 10x10x10 = 1000 instances) - but when having a large amount of 8000 instances (32 Million Triangles), 40x5x40 blocks, voxel raycasting is significantly faster ( 40 vs 13 fps ).

For triangles, I havent used any sophisticated occlusion culling. It would therefore be interesting to see how much more performance could be achieved using the voxel based umbra or the software based rasterization presented by intel.

For the ones of you that would like to experiment with occlusion culling, the source & data of the polygon benchmark can be downloaded [here].

Raycasting Outside
Raycasting inside

Triangles Outside
Triangles inside


Sonntag, 27. April 2014

Minecraft Style

Here a test how a 100% block landscape would look - basically like Minecraft.

Samstag, 26. April 2014

NVIDIA GTX580M vs ATI Radeon R9 270x @1920x1024

Today I tried to run the demo on a newer ATI 270x card of a friend. The result was better than expected as the ATI card achieved greater 100 fps for most of the time. On the GTX580M, the framerate was around 40 outside and ~30 indoors.

New features in this version: FXAA & loading / saving of level data.

ATI Radeon R9 270x
NVIDIA GTX 580M

Dienstag, 22. April 2014

Collision Detection

The next important feature is mostly working now : Collision Detection. I played a bit around to create a castle in the sky.

Samstag, 12. April 2014

New Sandbox Features

The editor now has a shelf and add/delete function for block setting as well as a box to indicate where to set a block. Further (2nd video), the new version features sound driven light effects that can be chosen when voxel sculpting.