Jump to content

  • Log In with Google      Sign In   
  • Create Account

dougbinks

Member Since 17 Jun 2012
Offline Last Active Dec 21 2014 06:49 AM

#5119732 Octree-based voxel lighting system

Posted by dougbinks on 28 December 2013 - 04:37 PM


I find it difficult to implement a good LOD in a voxel system that have seamless transitions when you change the distance. In your movie clip, there is such a change at 19s.

 

Yes, it's tricky. Eric Lengyel's transvoxel algorithm is one of the best for marching cubes (http://www.terathon.com/voxels/), and Miguel Cepero's Voxel Farm seams are pretty decent http://procworld.blogspot.fr/2013/07/emancipation-from-skirt.html, though I'm not sure what technique he uses as he has dual contour voxels. I use simple skirts for now with the skirt normal adjusted to minimize transition contrast, though I've not had time to cater for certain edge cases such as the one you spotted.

 

The main issue with shadow maps for me is the lack of light propagation in occluded volumes, such as caves. Otherwise they're great.




#5119702 Octree-based voxel lighting system

Posted by dougbinks on 28 December 2013 - 01:36 PM

Funnily enough I've been thinking about the lighting system in my own work recently, and there's some similarities as I'm using an Octree as well.

 

You can probably do decent per-vertex lighting the Minecraft way by subdividing the large voxels. In my own game I subdivide large nodes to the smallest voxel size for nearby regions, and use higher nodes of the branch of the Octree for level of detail in the distance. Hopefully you can see the LODs working in this (debug rendering) video. Using this approach has the advantage of fast vertex generation without seams, using skirts between LOD regions. So if you use this approach and have slow moving  or stationary lights you should be able to do fairly decent lighting which gives you some global illumination like properties.

 

I'd disagree that deferred rendering doesn't scale well - indeed that's it's purpose. Culling can be done via tiles in DX11+ (or equivalent in OpenGL), see Andrew Lauritzen's work, or you can use the stencil buffers. I've been considering using the voxel octree itself to do CPU side culling, but haven't looked into it yet.

 

I'm also considering voxel cone tracing or light propagation volumes, doing the work CPU side using the octree and then uploading the results asynchronously to either a light-map or 3D texture cascade. I've no results or even back of the napkin calculations of feasibility yet, but  will try to blog the results when I do.




#5094424 Dll plugin system: cross plugin "shared" classes

Posted by dougbinks on 16 September 2013 - 05:25 AM


Hmm, thats not really what I wanted to imply, the only real "problem" I had with the GetInterface solution (as well as AllEightUps) was the I required to declare a new interface with custom id etc.. for each type that was possibly going to be used, which at least in my had made it seem a little much work, where I'd prefered a more generalized method. In that matter, what are your thoughts on the method using typeid I proposed before?

 

In your case typeid would likely work as well as a dynamic cast - both end up calling strcmp in order to get cross dll compatibility. For this reason generally all performance aware applications like games generally end up writing their own type system like I've described, and additionally many games build without RTTI.

 


Guarantee *all* plugins, executables etc link to the dll version of msvcrt.

 

Note that it has to be the exact same version - the debug version is not compatible with the release version.




#5094247 Dll plugin system: cross plugin "shared" classes

Posted by dougbinks on 15 September 2013 - 10:19 AM


Ah, so I'd have to create an IInterface derived class for every type I want to convert to, is this correct? Doesn't that lead to having to distribute the interfaces I want to convert to the end user after all?

 

If you want some form of fast type conversion without dynamic cast you'll need an interface type which you derive from, yes. In order for a plugin writer to be able to use code, they need the declaration of that code at minimum - there's little use being able to cast a type to another type if they can't then use that type. So yes you'll need to distribute interfaces for the functionality. An alternative is to write a message passing or signal/slot type system, but this still requires that you define some way for programmers to understand how to use this.

 


Does that mean I have to eigther define the interfaces for all common types in the engine as part of the dll interface, or have the interfaces included by the plugins header file (which I'd want to avoid if possible); or am I really missing something? (some explanatory pseudo-code would be nice, in that case though )

 

Not quite sure I'm getting the issue here. If you want someone to be able to use an interface they need the declaration of that interface, which is usually in a header file.

 


I quess that would work, so I'll consider it a close option in case it is necessary, premature optimization and whatenot (or, lets add, me being to lazy to rework this part yet). As for low level systems, that certainly can be a nice addition, but I've seperated my low level render systems so that they are controlled via a gfx-layer, that is used by the component system, so that this wasn't really an advantage here, so there is no need/function for using anything from the entity system directly anyway ^^

 

It's worth your while following your current course through to completion if you've already got some way in. The issue I'm referring to is not really a premature optimization, but just a good point to start. There's some good material to be found by searching the web for information on data oriented design (often referred to as DOD). It's also a very good principal to not overly generalize systems until you need to - there's some good information on that in this blog and comment discussion.




#5094209 Dll plugin system: cross plugin "shared" classes

Posted by dougbinks on 15 September 2013 - 06:22 AM

I can't answer your question specifically, but a few ideas here might help:

 

A standard way of getting around dynamic casts is using a GetInterface method, passing in an interface id. That id can be declared in the interface header file as a static member of the interface structure/class in such a way that you can then use template methods. You can see something similar in the GetInterface members in this file.

 

 

As an aside, for performance I'd not use strings but a string hash or id. You can easily convert by adding a function to get the hash/id, use this outside the loop and then use hash/ids inside.

 

One other note is that if you're iterating through entities getting a component you should likely consider having that component stored in it's own array and then iterating through that.




#5093999 practica usability of linked lists

Posted by dougbinks on 14 September 2013 - 08:15 AM

A common technique I use is an array containing the items and a next index. Using indices rather than pointers gives access as fast as a pointer (using unsigned so as to avoid sign conversion), and simple load/save since you can binary write and read the data without any pointer fix ups. For an example use case see this blog post.

 

I also tend to use a number of fixed sized arrays to contain the items, so the index now becomes a block-index and node-index. To add more memory you create a new block, which gives good cache locality and no need to copy data when growing the size of data.




#5093997 How Useful is SVG?

Posted by dougbinks on 14 September 2013 - 08:03 AM

If you're interested in SVG, Mikko's NanoSVG is pretty handy.

 

An interesting alternative is to use a font if you already have font loading & rendering. You can make fonts from multiple SVG files using various tools, and then load then using and render them using whatever GUI or Font system you use, scaling to the appropriate size for your screen resolution.




#5093987 implementing scripting

Posted by dougbinks on 14 September 2013 - 06:56 AM

For communication between DLL's and EXE's using C++ a commonly used technique is to have virtual interfaces to systems, as this way you can pass around a pointer to a structure which holds the pointers to the interface of each sub system. This is the technique we used in Runtime Compiled C++ and it's also how the CryENGINE passes around interfaces using gEnv.

 

For a look at what a system table looks like see this file.

 

Exporting classes without using virtual interfaces is not simple in general, for an overview have a look at this post on codeproject. Using a virtual interface makes things alot easier - they don't have to be pure virtual but this does help to eliminate mistakes. Make sure to define a virtual destructor to prevent the memory created in one module being freed in another.

 

Feel free to use any of the code in RCC++, we use a liberal Zlib license and you can just use which-ever parts you need.




#5030984 Animations

Posted by dougbinks on 11 February 2013 - 04:16 AM

Not sure if this is useful, but came across this 2D animation package recently: http://www.synfig.org/cms/

 

It can export to multiple .png files, which you should be able to stitch together into your sprite sheet (google texture atlas tools if you want to find something to do this for you).




#5030326 OpenGL and Mac: No D3D11 level functionality?

Posted by dougbinks on 09 February 2013 - 02:59 AM

Also you should be aware that not all features are implemented in hardware, even if they can be. So my MBA 2011 can do geometry shaders in hardware on Windows Bootcamp, but on OS X they run 20x slower and the CPU utilization goes to max on one core - so they're implemented in software!




#5028354 Anyone here a self-taught graphics programmer?

Posted by dougbinks on 03 February 2013 - 09:11 AM

I started with the ZX81 when it came out, initially BASIC and some minor modifications to game program listings before I accidentally started learning and using assembly, on Z80 then 6809 and 68K. Later on I got a part time job with a company doing programming whilst at University doing Physics (C along with a load of esoteric stuff like Relayed-ladder-logic), but I got hooked on experimental physics research and ended up doing that for the better part of a decade, continuing to program and do graphics rendering for visualization at work, and for fun at home.

 

It was a great experience to start with learning on my own how to render a line in 2D, then polygons with those lines in 3D and so on. As a physics researcher I was able to use SGI machines, and so learned Iris GL, then when the 3DFX appeared on scene played around with their API Glide. When the NVIDIA TNT came out, along with a great OpenGL implementation, I started moving much of our code over to PCs which saved us lots of money - and I saw the huge change which was coming to consumer graphics so jumped ship and made a shareware game (C++ with OpenGL and OpenAL).

 

That game landed me a job in the games industry, where I eventually took on graphics programming then lead programming roles before ending up as a head of a medium sized games studio, before moving to Germany to run Crytek's engine department. More recently I worked at Intel in their Game Developer Relations department, but I'm now back as an independent developer making my own game.

 

It's an exhilarating business to be part of. Those of us old enough are lucky to have started learning before the complexity and abstraction of graphics APIs appeared, which makes it hard to really learn rendering if you're not disciplined enough to keep to the basics until you master them. But on the other hand the internet is such a great research tool - I can remember having to get on trains to go into the nearest city or large town so as to search through libraries and bookstores for something with information, or by hand disassembling code to figure out how it worked. Nothing beats just learning by doing, though if you can go to University then do so as being around loads of intelligent people roughly your own age is just amazing.




#5019024 Mesh file format?

Posted by dougbinks on 08 January 2013 - 07:23 AM

I'd recommend using Assimp as part of your asset pipeline if you're new to this and/or don't want to write your own. However I'd also move to using your own format for the game, by processing the original source files (.dae etc.) into your own format on load and then caching the result so that any future load can see if the source has changed and if not load the cached data. Then you only need to distribute the cached files, normally in a zip container (packed format). This is fairly standard in the industry, and easy to implement.

 

Your own format should mirror the binary in game format as closely as possible since it doesn't need to be backward compatible or cope with endian-ness or other cross platform issues since the asset pipeline deals with this sort of thing. This also makes it really easy to write your own format.




#4998810 Is SFML a better choice over SDL?

Posted by dougbinks on 08 November 2012 - 03:57 AM

Note that if you intend to use OpenGL directly for graphics then the peformance of SDL vs SFML in this regard is not relevant, since you'll not be using them for rendering.


#4996131 Compiled vs Scripted Physics Calculations

Posted by dougbinks on 01 November 2012 - 04:11 AM

I ask because I have been migrating more and more code into scripted languages and over the course of several discussions have come to realize that I am likely still under-utilizing scripts.


I think it's important to ask yourself what your priorities are. Scripting languages have a number of issues of which performance is only one, especially when combined with other languages due to debugging and interface barriers. For this reason many of my colleagues and friends in the games industry have been moving away from scripts to trying to use data driven systems and graphical interfaces (such as Unreal Kismet / Crytek Flowgraph etc.) for designer editing of behaviours.

A high performance physic system seems an ideal space for using a compiled language like C or C++ with all the tools available, and low level capabilities such as intrinsic access to SIMD arithmetic and efficient multi-threading. If you're looking for an easier way to program SIMD then you may want to look at ISPC.


#4993372 Unreal Engine... How did they do it?

Posted by dougbinks on 24 October 2012 - 03:42 AM

If anyone is following this thread still and using OS X, they might like to know we've recently added OS X support (only tested 10.8 and XCode 4 Clang++ so far). Would appreciate any feedback.




PARTNERS