Jump to content

  • Log In with Google      Sign In   
  • Create Account


spek

Member Since 11 Apr 2005
Offline Last Active Jun 22 2014 01:16 PM
-----

#5156679 Doing local fog (again)

Posted by spek on 29 May 2014 - 05:17 AM

T22_FoggyMetroTube.jpg

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".

 

 

Sorting

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
     generator.renderVBO();

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

 

 

 

 

@Hodgeman

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?

-edit-

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:)

 

 

@Krzystof

Thanks for the reads! Starting now smile.png




#5155848 Screenshot of your biggest success/ tech demo

Posted by spek 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 spek 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 spek on 01 March 2014 - 10:23 AM

Edit

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

http://www.kilobolt.com/

 

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 spek 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 spek 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?

 

Greets




#5104850 Ray/Path tracing questions from a dummy

Posted by spek on 27 October 2013 - 02:35 PM

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

http://graphics.cs.williams.edu/papers/PhotonI3D13/Mara13Photon.pdf

 

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.

 

Cheers,

Rick




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

Posted by spek 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 spek 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.

 

 

 

UDK

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 spek 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 spek 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.

 

Greets,

Rick




#5053712 Light halos, lens flares, volumetric stuff

Posted by spek 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

http://john-chapman-graphics.blogspot.nl/2013/02/pseudo-lens-flare.html




#5036314 Writing to Render Target from Itself

Posted by spek on 25 February 2013 - 07:08 AM

You can read while writing (at least on all my nVidia cards), but when you grab neighbor pixels around your current locations -thus pixels that might be processed at the same time- you'll get artifacts (read weird colors). So for blurring effects that typically grab a region around a source pixel, I'd say play Ping Pong.




#5035771 Starting with GL Instancing, advice?

Posted by spek on 23 February 2013 - 09:37 AM

Hey, I'm thinking about implementing Instancing, but before doing so, I need some general advice.

 

So far, most of the rendering is done by looping through (sorted) lists and call a VBO for each object. In some other cases, like drawing a simple sprite, I still use the good old "glVertex3f(...) <4 times>) method. And then for particles, I use a VBO containing many particles that can be updated with OpenGL Transform Feedback.

 

It makes sense that using Instancing helps when rendering lots of the same object (but at a different position, or with slight differences). But in practice, most of my objects only come in small numbers. 3 boxex, 5 decals, 1 barrel, et cetera. Does it still make sense to implement instancing, or does it actually slow down things with overhead? Or to put it different, when rendering a single quad, is instancing equal or faster than doing it the old 4x glVertex3f way?

 

 

Second, some of my objects are animated, and use Transform Feedback to let a Vertex Shader calculate the skinned vertex positions. Each animated model would have its own secundary VBO to write back the transformed vertices. This takes extra memory of course, then again the amount of animated objects is very small compared to the rest. I'm guessing this technique does not co-operate with instancing in any way right?

 

 

Third. My meshes use a LOD system. So when getting further away from the camera, they toggle to a simplified mesh. Is it possible to put all LOD models (usually I have 3 to 5 variants) in a single buffer and let the Instancing somehow pick the right variant depending on the distance? Or would using LOD's being less needed anyway?

 

 

Any other things I should keep in mind when working with Instancing?

 

Merci beaucoup

Rick




#5032689 Performance & Struct sizes

Posted by spek on 15 February 2013 - 09:38 AM

All right, seems I'm a bit too concerned then hehe, other than the struct size should be dividable through 4 on a 32bit system, to put it simple. So, whether a struct would be 28 or 32 bytes wouldn't matter in that case.

 

Yet, I've read (a long time ago) that the programmer chose for a specific (small) struct size in complex algorithms such as pathfinding, so it could be easily "cached"... I know why things are cached, but forgot how it exactly worked.

 

 

Delphi is not padding all structs in my case, since I specifically tell those structs to be "packed" in some cases. Usually in cases where the struct is also stored in a binary file to keep things compact and easier to predict.

 

Thanks






PARTNERS