Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Apr 2005
Offline Last Active Aug 23 2016 02:31 AM

#5252326 Many (IBL) CubeMaps / Bindless Textures

Posted by on 15 September 2015 - 04:15 AM

That doesn't sound crazy at all. Let's see if I get it straight:


It works a bit the same as ("old") Deferred Lighting, where light volumes (spheres/cones/...) were rendered into the scene, only affecting geometry it intersects. I'll use a "roughness" G-Buffer produced earlier to "blur" properly (taking multiple samples and/or picking lower mipmaps from the probe).


In the alpha channel we could store the weight (based on distance between pixel & probe centre and its radius; "attenuation"). It may happen 2 or even more probes overlap the same pixels, so we use additive blending to sum up both colors & weights. Finally we grab the produced "Reflection/GI texture", normalize it, and add it to the rest of the scene. Since I'm also using Screen Reflections (I can involve that here as well. Pixels that can make good use of realtime reflections, should use no or a lower weight for pre-baked reflections.




You know what, that sounds a whole lot easier than the tiled approach I had in mind. Only downside is that I'll have to resample the G-Buffer for each probe. Then again there won't be that many (overlapping) usually. And I guess its still a good idea to use a cubeMap array (or bindless textures) so we don't have to render probes one-by-one, switching cubeMap textures in between. But then I could first render the low quality (small-res cubemaps) array, then a high-quality array for example.

#5236965 Implementing (Lua) Script efficiently

Posted by on 26 June 2015 - 01:08 PM

I'm at the point of adding Lua script support in my engine. To override object events (onCollision, onUpdate, onWhatever), trigger events, UI interaction, and so on. About half of these scripts are only called "sometimes", when needed, yet other events may occur relative often, which makes me worrying about the performance a bit.



I did something similar a long time ago with Python, and then chose to collect all code pieces first, dump them in 1 large file, pre-compile it, get all functions from the script and register all my "API" (stuff the script can call from my engine) functions. So the whole pre-compilation and setup only had to be done once.


Grabbing all code from all possible entities, and then (re)naming it to ensure each entity class had its own unique functions was quite a task though. So before going that route again, I wonder if its worth it. Plus I'm new to Lua anyway.



So let's say if we have 100 different entities (monster, shotgun, medkit, door, lightswitch, ...), each with a bunch of functions (onClick, onHit, onUpdate, onXYZ, ...). What would be the best way to deal with these scripts ->


A: Just call & compile the individual functions on the fly when they're needed

B: Give each entity its own script (and to the registering for each script again)

C: Collect all code, make 1 huge file (with a lot functions inside!), register once

D: Something different? 


My feeling says B is the clean & comfy way... but maybe not the most efficient way, although if it only means a slight longer initial loading time... I'm fine with that.


#5207864 ShadowMapping in the year 2015?

Posted by on 31 January 2015 - 09:41 AM

Gentlemen / gentleladies,


Each time when not taking attention, the 3D-rendering world has been drastically changed, so I wondered what the current / common way of shadowmapping is.


About seven years ago, I implemented "Variance Shadowmapping". Basically rendering a depthMap for each shadow-casting lightsource (spotlights / point lights), and then doing a depthtest to determine whether a given position is shaded or not. And some additional math for the soft edge.


My main issues with doing ShadowMapping this way, are:

  • Got to render a depth-pass (possibly each cycle) for all contributing lights (and more than 1 for point-lights!)
  • Testing which lights actually attribute (directly) can be tricky - in cases where the light is out of sight, but its shadows aren't
  • Looping through lights in a single pass requires either a lot of shadowMap(depth) textures, or all maps being packed in one bigger "atlas" texture
  • Depth-testing requires some margin to avoid banding or self-shading issues. But this margin can also lead to "leaks" 
  • Quality suffers over distance due limited texture resolutions (typically my maps are 256, 512 or 1024 ^2)


The distance issue can be partially solved by using cascaded-shadowMaps, but so far I only use that for one "major light" (usually the sun or moon), due its additional complexity. The leaking / accuresy problem might be fixed with 32 bit maps (I only tried 16 bit so far). Don't know if that is standard nowadays.




Is "ShadowMapping" (and the listed problems) still the case? Or are there better/smarter/faster/nicer ways these days? I've been reading bits about "Physically Based Rendering" and "Image Based Lighting", but I don't see how that would solve or improve this problem, as -correct me if I'm wrong!!- IBL is based on (pre)baked probes/nodes/cubeMaps, and PBR is a global term for replacing dirty hacks with a more realistic range of values, parameters, and techniques.









#5156679 Doing local fog (again)

Posted by on 29 May 2014 - 05:17 AM


Implemented the "Deferred Particle Lighting" technique Frenetic Pony mentioned earlier.


And I'm pretty pleased, although there is a catch when using larger and/or moving particles. Bigger particles (say at least half a square meter) suddenly change color when moving in or outside the shadows. Which is a logical price to pay when only lighting the center. Maybe it can be improved a little bit by lighting the 4 billboard corner vertices instead of the center "particle point".




Next step is to do something about the sorting / better blending, as the (moving) particles tend to "pop" now. I didn't read the "Weighted Blend Order independant" paper from above yet, but I suppose it doesn't need any sorting? In case I do need sorting, I'm not so sure if my current system works. Instead of 1 giga-VBO that provides space for all particles, each particle-generator has its own VBO. So sorting withing a generator works, but I can't sort all of them in case multiple particle fields intersect. I also wonder if sorting out one big VBO would be useful at all, since I still have to render the individual particle generators one-by-one:

for each particleGenerator
     apply textures / parameters / shaders for this effect

Not being able to perfectly sort everything won't be a very big drama, but nevertheless, any smart tricks there?






Thanks for the hints! I'm using multiple blending modes mixed now (additive, multiply, modulation,...). You think, asides from emissive particles such as fire, that a single methods can be enough to do both additive "gassy" substances, as well as smoggy stuff that darkens the scene?


Stupid question, you already answered that. Dark color but high alpha darkens/replaces the color. Bright color & low alpha adds up. Thus it works for both situations. Nice:)




Thanks for the reads! Starting now smile.png

#5155848 Screenshot of your biggest success/ tech demo

Posted by on 25 May 2014 - 06:28 AM

Yup, you can find quite a lot when clicking the blog link below.


Plans/hopes are to release 2 more demo movies this year, as the last one (from the 2 pictures above) was released begin 2012. Time for something fresh. Unfortunately finding enough help on the artist/3D front turned out to be more difficult than actually programming the darn thing. Just fishing and hoping for talents with plenty of free time to knock on your door, isn't going to happen. Or well, it does happen sometimes when new demo movies arise. But then keeping them involved and motivated on a slow progress game, is really, really hard.


One idea, or maybe actually last-hope, is to raise a bit money via Kickstarter once the official next demo is released. Not to collect then thousands of dollars, but just a small budget so I can pay the artists per asset. Like 12$ for a chair, or 25$ for somewhat more complicated tasks. Not much, but always better than nothing and hopefully enough to keep the sirup streaming. At the same time being able to pay a little bit also puts me in the position to demand a bit more (speed). Now I can only smile and be thankful if someone delivers, but frankly that's not enough to keep everyone modeling & drawing. In Utopia maybe, but not in the real world where a man has to earn bucks for his household.

#5155811 Screenshot of your biggest success/ tech demo

Posted by on 25 May 2014 - 03:01 AM

Couldn't resist. A bit old, but anyway



Attached Thumbnails

  • radarBlob2.jpg
  • ControlPanel1.jpg

#5135655 Picking directions for making a little (mobile) game app

Posted by on 01 March 2014 - 10:23 AM


Instead of Qt / Cocos2d-x, I made a start with Eclipse & libGDX, using this nice step by step tutorial:



And the nice part is that libGDX comes with a setup that already generates your project/framework for multiple devices if you like (Android, iOS, PC, webbrowser). With minimum programming, I already had some sprites flying around on the (Android) phone. I know that's still a far throw from an actual game, but being used to making harsh engines for years before you could see something nice on your screen, that's a real relief!


Thanks for pointing me here guys!

#5105967 Building a Modern 3d Game from the Ground Up a Realistic Goal?

Posted by on 31 October 2013 - 09:28 AM

Hehe, thanks for noticing.


The project is still going on indeed, and I can tell you, doing everything yourself is an infinite amount of work. I don't mind it because it's a big hobby, and it forces me to keep a bit up-to-date with modern technology. Or well, at least I try. It's sometimes frustrating to see you're always behind the facts. No matter how hard you work, AAA engines will be ahead, and smart guys write papers faster than you can implement. I always thought skill would be the crucial factor, but more important is the amount of time you can&want to spend on your project.


And at some point, it becomes so huge that maintenance is getting hard. A perfect engine would be made of modular 100% tested/documented -> working "blocks". But when doing it alone, you simply don't have time to make everything perfect. With as a result that I often waste hours/days on updating old code or tracing bugs in stuff I made a year ago.


In my case, another limiting factor is making the actual graphics. I can draw and model a bit, but certainly not on a professional level. Yet I try to make the game look as good as possible, so I'm dependant on the very limited time of a very small group of artists that is willing to help me in their free hours. You can program supercode, but without artists that generate maps, props, sounds or textures on the fly, you still have nothing. 60" flatscreen or an old tube, an ugly woman on the TV will always be an ugly woman.




That said, it all depends on the size, goals and eventual help you can get. Making a 2D platform game is far less complicated, and thus far more realistic. A 3D engine could be done as well, but be careful not to get sucked away in the graphics-black hole. If you can live with lower end graphics, life gets a lot easier :)

#5105135 Ray/Path tracing questions from a dummy

Posted by on 28 October 2013 - 02:20 PM

Thanks for the comment. You're right about expanding work indeed. If we had to ray-trace a game environment from a 2002 game, it might be quite possible by now. But geometry, camera-view and lightcounts keep increasing. Yet, I was a bit dissapointed that even very simple scenery from the OptiX demo's ran like a clogged toilet here. Either my computer is truly lazy, papers lie about their performance, or they are doing some radically different. I don't know.


Well, as much as I love to learn about raytracing, I'd probably stay away from it for now. Yet, I still wonder how the mentioned paper seems to reach somewhat reasonable speeds (and that for Photon Mapping, not the easiest thing in the Raytracing universe). Am I missing something?



#5104850 Ray/Path tracing questions from a dummy

Posted by on 27 October 2013 - 02:35 PM

Regarding realtime G.I. / Photon Mapping, shortly ago a guy suggested me this paper:



It shows a way to "quickly" sample photons using the GPU, using a tiled technique (somewhat similiar to Deferred Tiled Lighting). Although I know the papers usually sound better than they actually are, it said to have reasonable framerates, and the end results looked good to me. The paper doesn't describe how to quickly emit / evaluate rays though, it focuses on the 2nd "gathering" step.



Anyway. Just out of curiosity, a few questions about ray/path-tracing & for Photon Mapping:

* What is a rough indication of rays to shoot for a single point light to get somewhat reasonable results? Thousand? Hundredthousand?

* What kind of raytracer technique would that paper use to reach such framerates? My experience with rays is that they are VERY slow

* How the heck does a GPU based raytracer perform collision detection with complex structures (like the warehouse in that paper)?

* Is nVidia OptiX a good choice in your opinion?

* Would something like OptiX run on a "normal" game-computer within ~4 years?



In my mind, if you don't launch a very f#cking big amount of rays per light, you get those old grainy CD-ROM game cutscenes which actually look worse than all the fakes techniques we have so far. Obviously, increasing the raycount is an easy to tweak parameter, but I really wonder how realistic the results of that paper are.


15 minutes ago, I downloaded OptiX. No idea how it really works yet, except that its a very basic (thus flexible) raytracer framework, using CUDA (and the GPU?). But the demo programs ran like crap with a whopping 3 FPS average for most. Of course, my aging 2008 laptop is guilty, but does a modern system really makes that much of a difference? And otherwise, is the expectation that the hardware keeps growing fast enough to deal with it? I remember raytracer fans saying that it would become reality 8 years ago already, but a system that can do it practically is yet to be invented AFAIK.


Basically I'm trying to figure if it's worth the effort to dive further into OptiX now. Of course, it always is worth to learn, but having limited time you can't learn & try multiple things at the same time. But in case of sceptism, how did nVidia get those good results (GeForce 670, full HD resolution, Sponza theatre)?




Another question. I'm guessing the collision detection part is the biggest performance killer. I've heard of Kd trees and such, but never implemented them so far. But how would a GPU based Raytracer access such trees? It requires complicated stories like we had with VCT octrees again right? Would OptiX do this for you btw, or is the programmer 100% responsible for writing collision detection kernels?


Finally, the paper mentions that "Images Based path tracing is even faster". I guess that means they are using depthmaps instead of complicates trees. I can see the benefit, but GI based techniques need more than the Camera can see, or the data for collision detection would be incomplete. Its possible to combine depthmaps (from camera, light shadowMaps, fixed placed cubeMap "probes"), but either we have to loop through a big bunch of textures for each collision test step, or we have to merge them into a single volume texture (which requires a big amount of memory, or ends up very low-res). At least, as far as I know. So I just wonder what kind of smart trick they are refering though in that paper.




#5084859 Is there any way to make animations using physical dolls?

Posted by on 11 August 2013 - 12:50 AM

Being used to make models out of clay, thus using your hands, that "Qumarion" sure looks a whole lot easier than moving joints with the mouse. 750$ is less then I expected as well (though still way too much for hobby purposes). However... what if you need to animate an animal? Or a 4-arm Guru? Guess they need to add some Optimus Prime transformer abilities to that manequin as well!


The technique behind it doesn't sound that hard by the way (except that it is being implemented on a small scale on a sweet looking puppet). Just a bunch of angle sensors, a chip that measures them, and sends these values to a PC that translates them into join rotations. At work we have a lot of metal arms and inclinometers to measure angles on machines. Got to make a harness with those some day to have my own low budget motion capture studio hehe.

#5083389 Uber (Compute) Shader construction

Posted by on 05 August 2013 - 05:43 PM

It gets slightly more complicated, as there is no "level-start". The whole world roams, so in case I shouldn't load all possible shaders at a time, they need to be loaded when they become relevant. So most of the texture and world data is streamed on the fly already. Using OpenCL instead of GL for the particles btw, dunno about the options there to stream things smoothly.


It's hard to tell how many different particle effects will be generated really. Thousand is probably a bit of an extreme example, and a minute more or less loading doesn't hurt that much anyway, since a lot has to be loaded initially anyway. That still doesn't mean I should follow the dumb & easy path, But for making decissions, I'm more interested in the performance benefits (or lack of), and flexibility. If each different particle effect gets its own shader anyway, I can hardcode all parameters, and allow to add custom chunks of code for advanced motion, rather than trying to do everything with a limited set of parameters.




For example, consider physics. A particle either just falls like a rock, like a feather or tree leaf. Maybe it doesn't fall at all because it's a dust cloud, or a swarm of stinky flies that does random movement. With a variable gravity vector you can come quite far, but more advanced movements such as the flies require more options/variables, or a different base shader to start with. Combine that with the many other features (color, size, opacity, collisions, wind, spawn locations, ...), and the list of combinations becomes infinite. In my current "solution", I'm just using one shader with a big bunch of variables. But three things bother me:

- The shader isn't very optimized (a lot of features are rarely used)

- Not switching shaders, but I need to set quite a lot parameters nevertheless (how bad does that hurt anyway, setting params?)

- Works good for basic effects, but too stiff for more advanced stuff (cigarette smoke, A-bombs, whatever)




However... probably 50% of the particles still uses a simple program. Bit smoke here, a bit of dripping dirty stuff there... Impact debris doesn't vary a lot, except for the texture, density and gravity influences. So probably I should try to make shaders reusable in such cases anyway (so I can also sort on them, saving a few switches maybe), by offering a small listing of common used parameters / features. More advanced effects should have the flexibility to create their complete own programs, without getting restricted. But advanced effects aren't the majority of the particles, so it shouldn't produce many hundreds.





Still curious, does anyone know if a variable (a gloss factor for example) is stored as a hard-coded constant in the shader, or does the engine pass the variable so the same program can be re-used for multiple materials with different gloss values? If not, don't they end up with thousands of shaders as well?


The most mind boggling part of this whole thing, is to pick a path that is efficient, but also clear and somewhat easy to use, understand and implement. Highly optimized strategies often aren't. That's what I like about the UDK node approach, it seems very consequent and understandable for non-programmers. No idea what kind of dirty performance tricks are done under the hood though...

#5083335 C++ rendering engines to look at for learning purposes

Posted by on 05 August 2013 - 02:39 PM

Maybe not exactly what you are looking for, certainly not regarding modern shader techniques, but possibly some good lessons into general engine coding anyway;

I believe Quake1/2 and Doom3 (and maybe more id games) have the full source available as free downloads.


The older games are just C btw, Doom3 might be C++ though I'm not 100% sure. Anyhow having a good idea how to structurize the engine as a whole (a game is more than rendering!) is certainly a valuable fundament.

#5082794 Uber (Compute) Shader construction

Posted by on 03 August 2013 - 12:16 PM

Hello there,


I never actually used the UDK development tools, but when looking at their material definitions -a bunch of nodes with texture or math functions connected to each other- I get the impression that the shader code is constructed by pasting small pieces of node-code together. Though less aawesome, I'm doing something similiar; specific shaders get constructed by enabling options and using IFDEFs in an ubershader.


Nothing new so far. But how about (numeric) parameters? For example, let's say we want to multiple a specular texture with a fixed RGB value of {64,64,75}. In my engine, this RGB color would be passed as a uniform float3 parameter when applying the shader. But it seems to me that UDK actually hardcodes these (constant) values as well into the shader.



I could be wrong of course, but it would make some sense. Using constants is more efficient than passing parameters. Then again the disadvantage is that you'll have to rebuild the shader whenever a value changes, and maybe more important, you will get a massive amount of slight-different shaders.



Now to the actual question, what would be wiser to use -mainly performance wise- in the following situation? I'm making a new Particle editor, and there are tons of modes and parameters regarding motion, colorizing, size, spawning positions, timing, opacity control, physics, collisions, and so on. Instead of passing a big bunch of vectors, colors and numbers, I could just hardcode them into the (OpenCL Compute) shader. Sounds like a plan Murdock, but I'm a bit worried about the fact that I will end up with a big bunch of shaders. If there are 1000 different particle spawners, there will be 1000 different programs as well, This dissallows eventual grouping on shader as well.




#5053712 Light halos, lens flares, volumetric stuff

Posted by on 15 April 2013 - 11:42 PM

Using a mini depth buffer to approximate visibility sounds smart, got to keep that in mind instead of doing traditional culling.


Hmmm, I tried soft particles before, but usually in narrow crowded spots they wouldn't be visible much, because they would always (almost) collide and therefore fade out. Well, that could be a matter of tweaking.


The biggest problem I had with glow-sprites, soft or not, were rectangular shaped lights such as fluorescent "tubes". The sprite can't rotate with the camera in this case, unless it scales itself depending on the view vector or something. Keep it a fixed rotation did the job for most angles, but as soon as you stand in a 90 degree angle, you still notice the flatness, if you can see the sprite at all.


That's why I was thinking about defining a 3D shape (such a sphere or cube) around lamps and then render a view dependant sprite in it. But I didn't implement anything yet, neither do I have a battle plan. But maybe someone else has experience?



@Frenetic Pony

That's a lot of formula's, usually my brains crash then :) But I'll give it a try and read, I always thought that Atmospheric Scattering, at least in games, was more for bigger scaled (outdoor) fog and skies, rather than doing glow sprites which are a very local effect? Either how, it needs to be a relative cheap effect as in my case I have many lights that can appear everywhere.


Anyway, thanks for the links!



Btw, maybe useful for others, I found this about implementing lens-flares