Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 12 Mar 2012
Offline Last Active Jul 27 2015 03:38 PM

Posts I've Made

In Topic: Looking for Multiplayer 3d game engine with tools

29 May 2015 - 05:41 PM

You have no clue what you are getting yourself into.:)


As far as i know there is no such thing as a "(M)MORPG Do-It-Yourself-Development Kit for Dummies". Multiplayer Games are hard work. Multiplayer realtime 3D games are even harder.

Further you arent really specific in your needs at all. The needs of a Shooter might differ greatly from those of a ... say RTS. Thus the engines would differ greatly in terms of rendering mechanics, networking etc.


I am with no means an expert on this topic though and i might underestimate your expertise greatly by packing you with the cliche "I want to write an awsome multiplayer game after i mastered HTML now!" guy... I Also dont mean to discourage you in anyway. Its just... if it fails - which has a great chance to be the cas specially in a 5 year project - you possibly wasted a lot of time for nothing.

Of course: You can learn a lot in the process if you do it right. But if learning isnt the goal than it is better achieved by smaller projects where failure isnt such a great trigger for frustration.

In Topic: When you realize how dumb a bug is...

26 December 2014 - 06:59 AM

Exporting a tree-structure as a visual output to another tool from a tool that doesnt provide positional data...

So yeah... Calculate them from the structure. Not that hard to do, right?


But i wasted like a shitton of time because the target tool had the undocumented feature to set everything with a x or y coordinate of 0 (totally valid value...) to 100 / 100. Searched for ages in my code and then just tried adding 1 to everything... and suddenly it worked.

Biggest derp in my recent programming carreer. :/

In Topic: Voxel Rendering Engine Tips

28 November 2014 - 06:23 PM

No, not really. Polygon based voxel renderers get really slow or too complex when you start trying to render all of them with a higher resolution than something like minecraft. Also, my main goal is to remove GPU dependency. So if I can get a complete fast CPU version working at a moderate voxel and screen resolution, with plenty of spare room for other game component processing, then my only problem I have to solve is how to best get my render buffers into video memory, which may result in forgoing API's like OpenGL and Directx completely.


This is not quite true, honestly.

Polygonbased voxel rendereres are still the fastest you can get at the moment with the graphics pipeline beeing optimized for such.


Sure, if you have tiny tiny cubes you've got a lot of stuff to render, but you can batch and optimize. Merge larger faces etc. That isnt too complex, especially if you use appropriate datastructes like an octree. In fact with an octree you got the "merged faces" as a bonus to the (in case of a sparse tree) really compact (comparably) memory usage.

If you want to get smooth you could as well roll with something like marching cubes (beeing the most known) or move to even more sophisticated algorithms like surface nets or other dual algorithms which optimize mesh topology to some extend.


With my (arguably modest) testing on this subject i found Polygonbased Voxel rendering to be a lot faster than the given alternatives like raytracing/marching etc.

In Topic: Share the most challenging problem you solved recently! What made you fee...

22 June 2014 - 12:08 PM

Not so much of a "Boy, how cool", but i dont want this thread to die. :P
So... My most recent accomplishment was a first running version of a iso surface extraction algorithm i thought of and implemented from scratch. The results are (almost) equal to those of the marching cubes algorithm, but since my algorithm extracts and then triangulates pathes from a grid LOD should be easily implementable ( Which i will have a look into soon. ) :P
So far its running pretty fast concerning its a very naive approach and just meant as a prove of concept... But a remake is in the forge atm and its goin good :P

"Complex" cases like a 6-Node Path are simplified atm thus details are lost, but this method (with the right implementation) Also allows for sharp features as tested with rotated cubes. This is a little fiddly, tho :P


I would post a picture of it, but as wireframe its just messy ( As usual: Iso surface with shit tons of triangles ) and i didnt implemented lighting for it yet so its just a clump of... well... Colored Triangles... Every color beeing the same. :P
If there is intereset i might post more details or try to implement a quick and dirty lighting solution for actual usefull pictures.... ^^"



DONT DIE, THREAD! The world needs peo... topics like you! (Or at least i do, against the boredom!)

In Topic: DX11 Hardware Voxel Terrain (your opinion)

25 April 2014 - 05:59 PM

It is indeed for generation on the CPU but i guess it still applies for the GPU.

Problematic with this approach is btw that you would need to implement a volumebased physicsengine or a physicapproach on the GPU that works with your extracted meshes etc.

Its hard to do, i think, if you need physics, that is.


But i didnt implement any of those algorithms on the GPU and i dont plan to, so i cant help that much with that. I just wanted to point you to some maybe helpful things :)