Don't you think all sliding doors should be magnetically suspended above the ground?
And just have some rails to "guide" them? :).
At least I do!
torsdag 31 januari 2013
söndag 27 januari 2013
Words...
Politicians are glorified parking attendants, they just waffle their way out of bullshit...
Ramsay 2009, still true
Ramsay 2009, still true
onsdag 23 januari 2013
Space sim physics
Every couple of years a decent space fighter game/sim is released. But while games such as freelancer are overall well designed and fun to play for the action and story line, they have completely unrealistic physics. From a dogfighting perspective they're boring - Just full pull and fire when u see your target... Try that online in a decent fighter jet sim and you're pretty much dead against any decent opponent, those fights are based on faints, traps and gaining the energy advantage over your opponent.
There are some niche games that do attempt more physically accurate simulations (such as Starshatter), but as it turns out space combat with realistic traditional physics is, to me, even less interesting.
Space of course has no obvious potential wells/differences/axes, unless you count fighting close to planets/other gravity/mass concentrations. Space (usually) has no high enough concentrations of mass (think "air") that you may surf on. - So any form of dogfighting discussion with energy maneuvering becomes pretty lame, long range guided weapons become death rays, impossible to evade without sufficient standoff/turn-and-run energy - meaning more boring fights.
Assume you're making a space sim which has something like bases/stations and capital ships/something man-made larger than a fighter. Let's also assume these structures have the ability to generate reasonably strong magnetic- or another type of field.... See where this is going? - There's your continously varying potential that your fighters may "fly/surf on". I'm not going to do all the math here but I bet a few well placed superconductors on your fighters would make for an interesting situation... All of a sudden it becomes important to maneuver through "dense space" to maximize turn rates ;).
Potential energy around planets/Earth is pretty boring after all, being (pretty much) spherically symmetric. All of a sudden, in a space game as mentioned before, you'd have capital ships battling with their own weapons as well as giving their fighters the best "sea" in between as possible. You'd need displays and sensors that give you a good idea of the potentials ahead and where to "sail/drift/surf" to maximize your performance and defeat your opponents.
There are some niche games that do attempt more physically accurate simulations (such as Starshatter), but as it turns out space combat with realistic traditional physics is, to me, even less interesting.
Space of course has no obvious potential wells/differences/axes, unless you count fighting close to planets/other gravity/mass concentrations. Space (usually) has no high enough concentrations of mass (think "air") that you may surf on. - So any form of dogfighting discussion with energy maneuvering becomes pretty lame, long range guided weapons become death rays, impossible to evade without sufficient standoff/turn-and-run energy - meaning more boring fights.
Assume you're making a space sim which has something like bases/stations and capital ships/something man-made larger than a fighter. Let's also assume these structures have the ability to generate reasonably strong magnetic- or another type of field.... See where this is going? - There's your continously varying potential that your fighters may "fly/surf on". I'm not going to do all the math here but I bet a few well placed superconductors on your fighters would make for an interesting situation... All of a sudden it becomes important to maneuver through "dense space" to maximize turn rates ;).
Potential energy around planets/Earth is pretty boring after all, being (pretty much) spherically symmetric. All of a sudden, in a space game as mentioned before, you'd have capital ships battling with their own weapons as well as giving their fighters the best "sea" in between as possible. You'd need displays and sensors that give you a good idea of the potentials ahead and where to "sail/drift/surf" to maximize your performance and defeat your opponents.
Kids' killer app of 2013/2014?
Another wierd idea. A smart phone app where you have the classic virtual pet, but with a twist!
This virtual pet hooks into the GPS, wifi and other available sensors of the device. In combination with communication to a (few) centralized server(s) your pet can run away, you'll need to find it by using a/the map application and GPS - your pet can also run to other pets' screens and "play", or ...make more pets? :P
Aw the possibilities are endless...
Will sell for $5. Extra DLCs available for clothing, toys, pet food.
Special offer for a twin pet, only $3.99!
If anyone feels like financing such a project I'll code it :P.
This virtual pet hooks into the GPS, wifi and other available sensors of the device. In combination with communication to a (few) centralized server(s) your pet can run away, you'll need to find it by using a/the map application and GPS - your pet can also run to other pets' screens and "play", or ...make more pets? :P
Aw the possibilities are endless...
Will sell for $5. Extra DLCs available for clothing, toys, pet food.
Special offer for a twin pet, only $3.99!
If anyone feels like financing such a project I'll code it :P.
On resource managment, c++, java, .net
Going into Java vs Native is a hopeless battle. Their respective crowds remain the same.
Let's just believe that there exists optimal tools for tasks with well defined boundaries.
For any hobby project my choice was usually Java (now it is Scala). At work, it's C++ or C.
I love working on the JVM because of how easy it is to set up server-client architectures, run multiple threads across platforms, guarantee cross thread visibility and for each error getting standardized stack traces with thread and code line references - out of the box.
But when it comes to what most people consider the flagship (or devil) of Java, the Garbage Collector, I don't like him. He might be fast, efficient, but he is only capable of a small range of tasks.
If you pile up junk on a big heap he will do his job fine.
If want to help out with your neighbors trash, the GC gets confused - Because the GC goes "lalalala, I only see your pile of trash". When he's at it (that is, collecting your garbage) you can tell him to also help your neighbor, but you can't order him to actually observe your neighbors heap of junk on his own.
Suppose instead your neighbor is a set of file resources, network resources, video card resources, exernal device resources, etc, the list can be made arbitrarily long. Automatic management and collection can't be handled by the GC, because he doesn't really know when things are no longer needed.
Enter C++ and RAII, and the wonders of smart pointers - you may reference count anything you like, and it works beautifully. You may argue all you want that java's try-with-resources or C#'s using pattern exist, but in reality they are nowhere near the capability of hooking into deterministic stack push/pop behaviour.
Dear Oracle: Would you please introduce a ref counting Generic class (RefCnted<T>, or RefCnted ifc that you implement) which does not imply automatic garbage collection, but instead behaves like a normal C++ smart pointer/stack object? JVM languages would be much richer with such capability. JVM byte-code is stack based afaik, pease let us use that power :).
Friendship compatibility test
When bored, there's always xkcd...
Favorites (not in any particular order):
http://xkcd.com/378/
http://xkcd.com/297/
http://xkcd.com/849/
http://xkcd.com/464/
http://xkcd.com/833/
http://xkcd.com/341/
http://xkcd.com/350/
http://xkcd.com/327/
http://xkcd.com/371/
http://xkcd.com/138/
http://xkcd.com/458/
http://xkcd.com/290/
Favorites (not in any particular order):
http://xkcd.com/378/
http://xkcd.com/297/
http://xkcd.com/849/
http://xkcd.com/464/
http://xkcd.com/833/
http://xkcd.com/341/
http://xkcd.com/350/
http://xkcd.com/327/
http://xkcd.com/371/
http://xkcd.com/138/
http://xkcd.com/458/
http://xkcd.com/290/
tisdag 22 januari 2013
A new years OpenCL GPU ray tracer
Something that has been bugging me for too long, so I had to start working on it.
Let's face it: Ray tracing is awesome :). Back in the day when I did my msc thesis my supervisor showed it to me: it was the first time I had really looked into it - I also saw OpenCL and GPU programming for the first time. I wrote a (judging with the knowledge I have today) crappy ray tracer for physics simulations for my thesis and passed.
But this christmas I wanted to redo it with what I've learned since then, and I wanted to do it for CG. Many articles I've read seem to point to one of the issues being: That it IS possible to use ray tracing as the primary rendering method for a somewhat simple but still interactive 3D game, but the cost of rebuilding the search trees/acceleration structures every frame is too high.
The overall cost of rendering a scene by rasterization is about O(n), where n is the number of objects/triangles/you name it. In ray tracing, supposedly, you should be able to achieve < O(n), but this is all broken because when scenes are animated/interactive, objects move and their acceleration structures must be rebuilt, supposedly every frame...If that rebuildling cost could be moved to <= O(n) while also keeping the tracing itself to < O(n), then ray tracing could possibly challange rasterization sometime in the future.
Given that this is a pretty heavily researched subject and that dozens/hundreds of smarter people than me are working on it daily (while I'm doing it when there's some extra spare time) it would be unwise to claim that the ideas I present here are new and revolutionary ;).
Insert question:
Why on earth would you want to rebuild the entire world's acceleration structure each frame?
Ok.......it's conceptually simple to code an implementation with just triangles and kd tree partitioning, or some general bvh method, whatever....what is to say that there is a universal super solution to everything - why should raw triangles in an acceleration structure be the key? (Just to make it clear I'll believe in voxel solution when I see a good one with shadows/reflections etc working decent in a dynamic game environment)
Ok. But anyway, let's propose a first method of solving the heavy acceleration structure rebuilds: Let's just have 2 acceleration structures which will be traversed in parrallel - One for dynamic objects and one for static (in all likelyhood, at least the first generation of ray traced games will have most of their scene's shapes static - like the majority of todays rasterized games!).
Another possible solution (which I've been experimenting with) is a simple variant of multi level acceleration structures: Top level structures enclosing instanced sub spaces/acceleration structures with their own rotated/translated/skewed/lalala coordinate systems.
Example: You have a top down game with for example a game like Diablo's POV. Imagine a coarse top level acceleration structure/grid which holds only references to models placed in it, and that each ray hitting a model then subsequently traverses the particular space/acceleration structure belonging to that model, with the transformations for this particular model instance. The second level structure may be of any kind (kd, grid, bvh etc), the ray initially only needs to know (e.g. in 1st pass for breadth first) that that particular sub space has to be traversed. One could add (e.g. for parts of models beloning to one bone in an animation skeleton) or remove levels as needed. Models could have pregenerated acceleration structures.
Also, I stumbled across some DAC(Divide and conquer) ideas for ray tracing, where acceleration structurs are built on demand, which would fit nicely into this, as you could generate coarse top level structures often and the lower level ones on demand (dynamic model complexity also comes to mind here)..
Anyway, all talk, here's my experiment in action:
http://www.youtube.com/watch?v=dSTfNg-uCqk
16 Stanford bunnies at 100 fps @ 1080p with shadows. OK that is actually a static scene with a single moving light source, but you'll have to trust me or just implement it yourself - that code uses a single bunny instanced 16 times in a coarse grid. The rays which intersect any models are transformed to that particular second level acceleration structure's coordiante system and continue from there.
The whole scene has about ~250k triangles, but is rather simple because most rays hit nothing at all.
Let's face it: Ray tracing is awesome :). Back in the day when I did my msc thesis my supervisor showed it to me: it was the first time I had really looked into it - I also saw OpenCL and GPU programming for the first time. I wrote a (judging with the knowledge I have today) crappy ray tracer for physics simulations for my thesis and passed.
But this christmas I wanted to redo it with what I've learned since then, and I wanted to do it for CG. Many articles I've read seem to point to one of the issues being: That it IS possible to use ray tracing as the primary rendering method for a somewhat simple but still interactive 3D game, but the cost of rebuilding the search trees/acceleration structures every frame is too high.
The overall cost of rendering a scene by rasterization is about O(n), where n is the number of objects/triangles/you name it. In ray tracing, supposedly, you should be able to achieve < O(n), but this is all broken because when scenes are animated/interactive, objects move and their acceleration structures must be rebuilt, supposedly every frame...If that rebuildling cost could be moved to <= O(n) while also keeping the tracing itself to < O(n), then ray tracing could possibly challange rasterization sometime in the future.
Given that this is a pretty heavily researched subject and that dozens/hundreds of smarter people than me are working on it daily (while I'm doing it when there's some extra spare time) it would be unwise to claim that the ideas I present here are new and revolutionary ;).
Insert question:
Why on earth would you want to rebuild the entire world's acceleration structure each frame?
Ok.......it's conceptually simple to code an implementation with just triangles and kd tree partitioning, or some general bvh method, whatever....what is to say that there is a universal super solution to everything - why should raw triangles in an acceleration structure be the key? (Just to make it clear I'll believe in voxel solution when I see a good one with shadows/reflections etc working decent in a dynamic game environment)
Ok. But anyway, let's propose a first method of solving the heavy acceleration structure rebuilds: Let's just have 2 acceleration structures which will be traversed in parrallel - One for dynamic objects and one for static (in all likelyhood, at least the first generation of ray traced games will have most of their scene's shapes static - like the majority of todays rasterized games!).
Another possible solution (which I've been experimenting with) is a simple variant of multi level acceleration structures: Top level structures enclosing instanced sub spaces/acceleration structures with their own rotated/translated/skewed/lalala coordinate systems.
Example: You have a top down game with for example a game like Diablo's POV. Imagine a coarse top level acceleration structure/grid which holds only references to models placed in it, and that each ray hitting a model then subsequently traverses the particular space/acceleration structure belonging to that model, with the transformations for this particular model instance. The second level structure may be of any kind (kd, grid, bvh etc), the ray initially only needs to know (e.g. in 1st pass for breadth first) that that particular sub space has to be traversed. One could add (e.g. for parts of models beloning to one bone in an animation skeleton) or remove levels as needed. Models could have pregenerated acceleration structures.
Also, I stumbled across some DAC(Divide and conquer) ideas for ray tracing, where acceleration structurs are built on demand, which would fit nicely into this, as you could generate coarse top level structures often and the lower level ones on demand (dynamic model complexity also comes to mind here)..
Anyway, all talk, here's my experiment in action:
http://www.youtube.com/watch?v=dSTfNg-uCqk
16 Stanford bunnies at 100 fps @ 1080p with shadows. OK that is actually a static scene with a single moving light source, but you'll have to trust me or just implement it yourself - that code uses a single bunny instanced 16 times in a coarse grid. The rays which intersect any models are transformed to that particular second level acceleration structure's coordiante system and continue from there.
The whole scene has about ~250k triangles, but is rather simple because most rays hit nothing at all.
Prenumerera på:
Kommentarer (Atom)