Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Aug 2002
Offline Last Active Sep 24 2016 03:22 AM

#5095098 Animation with obj mesh per keyframe in DX11

Posted by on 19 September 2013 - 12:34 AM

how can I interpolate
In line of concept, you cannot, because OBJ does not guarentee the order of vertices is coherent across different files. So you have those values somewhere but you don't know where. Consider moving to a more modern format.

#5094441 Level Generation

Posted by on 16 September 2013 - 07:37 AM

As to not get to far off track from my original question, why is the data oriented design better then the
first code example. I'm not questioning it's actual purpose or efficiency. I have just heard the name "data oriented design" before 
and would like to know what that is. You don't have to give me a full blown explanation tailored to me. I take links
It's more or less like equations, where we write x + 7 instead of two numbers. This does not come easily as we have to write stuff that adapts to every (meaningful!) configuration for us, thinking in advice what we need. Of course if I tell you what amounts to x + 7 you cannot give me an answer and similarly in code we cannot get a solution... but we have to write code which somehow outputs the correct solution for us every time. We do that by exploiting properties the data is guaranteed to have and to define those properties we need to define the problem.


So for example in a tiled world we might be interested in knowing, for each cell in the world (not each tile):

  1. how it look?
  2. is it passable?
  3. if passable, sound of footsteps
  4. if passable, deals damage?

So we might want for example to make a specific cell passable even though it typically isn't, because that's a classic for hiding secret goodies: going through a nonsolid wall. In general we have to decide which property is part of the world cell and which is part of the tile itself.

Instead of defining properties in code we define them in the data itself.

Let's assume for easy explanation we load each tile graphics from a file. Then the actual tile graphics data is not really relevant: we just have to load it up completely, pack it in a texture and draw a quad measuring - say - 2x2 world units.


But now I'd stop there and let you figure out what you need to pack in your world.

#5092627 Particle Collision

Posted by on 09 September 2013 - 12:22 AM

How would you go about determine if a particle collided with something? We finally got GPU particles working but for rain we want it to create a new particle on collision with the ground. How might one go about doing this?
The first "new gen" stuff I recall is Lutz Latta's "Building a Million Particle System". Also called "UberFlow". The performance was nothing short of incredible, considering it run on midrange Shader Model 3. It apparently ran on Shader Model 2 as well but I'm not sure.

I cannot find the original resource, but this presentation from AMD seems to include it.

Note that this system can make particles collide and react to height fields.


Another presentation from GDC2007 covers particle effects from a game in the Command & Conquer franchise. You might notice some similarities with Uberflow but it provides a major update and several artistic reasoning when it comes to why instead of how.


Main problem is essentially finding a way so particles can collide with arbitrary geometry without killing their perf. So far the only sure thing is that you cannot just push the whole collision geometry data to a PS. Will you go for the "subset" approach? Or maybe you'll prefer voxelization? I'm torn myself.

#5091740 Venting via Twitter

Posted by on 05 September 2013 - 02:06 AM

How do you all deal with the day-to-day minutiae of corporate life?
I vent on social networks as well. Most of the time, nobody understands. And that's fine for me.

#5091733 no gpu onboard ?

Posted by on 05 September 2013 - 01:49 AM

for example external gpu are
5x, 10x (?) faster?
Goes like this:

Intel - it or miss. Often not properly documented in leaflets. HD4000 (some ivy bridge chips) is minimum considered decent. Haswell chips have a "Crystalwell" option, 128MiB of L4 cache. This is the fastest integrated option and the most expensive, marketed as "Iris pro" if memory serves.

Intel graphics is not really an option for gamers. HD4000 is the turning point as it's more or less as powerful as a card worth 50 bucks. Crystalwell is a real game-changer, I'd say it's as fast as a 80 bucks stand-alone card.

AMD graphics is better (with Crystalwell being the exception). Worth, at best 65-70 bucks.

In the end, they all get trashed by cards worth 100.

#5090089 what's the C++/OOP way to implement this architecture ?

Posted by on 29 August 2013 - 06:21 AM

Going defensive much?

You don't need to.

I think you should start writing something (regarding this) if you haven't already.

#5090013 Pushing Objects in Bullet Physics

Posted by on 29 August 2013 - 12:07 AM

The above methods doesn't move the object according to the hit point, I have btVector3 rayHitPoint
Then I suppose you need applyImpulse or applyForce. You might have to start using the documentation sooner or later Medo.

It doesn't work, though I also need to determine "how much impulse will be applied"
You're really supposed to work with "force". The impulse is a different thing and does not make much sense in terms of realistic simulation but it comes handy for artistic purposes. The applied force depends on the game logic, in the real world it's often constant for bullets in the sense they are pushed out of the firearm with a known, fixed force.

#5089098 Pushing Objects in Bullet Physics

Posted by on 26 August 2013 - 12:32 AM

If the object is dynamic, just resolve the collision ray, cast the obtained object to btRigidBody and apply and impulse to it.

Ok, it's not so easy. Many things can go wrong:

  • I assumed the object was dynamic but that could be not the case in reality. It could fail to cast to btRigidBody  or
  • it could still cast correctly but be a kinematic or static

In the end this will only work if the object is properly authored (but that's hopefully an easy assumption).


If the object is static... I suggest to give up. It's not impossible to destroy it and re-create it dynamic. It might even make some sense in many situations. It didn't in my last project and sure you need some static objects to stay static whatever happens to them. In general, there are artistic reasons for which some objects cannot move, beyond the technical.


Kinematics are the real trouble. I think there are good gameplay reasons for which they shouldn't be moved at all but in the past I had a long discussion with a designer that seemed to think otherwise. The main problem with pushing kinematics is what I dubbed "kinematic invariance problem". A kinematic object, when pushed should be working as a purely dynamic object. This is not the case: if you just write your own integrator, there's a high chance its behaviour won't match dynamic.


But I suppose you'll be happy with just pushing dynamics around, are you?

#5089094 So how does this look?

Posted by on 26 August 2013 - 12:10 AM

Pretty good! You know, I never had the time to deal with vegetation so I appreciated it a lot.

#5089093 Using padding to make vertex structures align?

Posted by on 26 August 2013 - 12:08 AM

In my experience, padding was irrelevant on most, if not all hardware I tested.

That said, I stopped collecting so accurate data a few years ago as the hardware grown far beyond my necessities. If there's not enough workload then there's nothing to measure. I usually spend 10-15% on vertex transform so I sure wanted to focus on pixel techniques.

Whatever this will be your case it's an open question but I suggest to just move along.

#5089092 what's the C++/OOP way to implement this architecture ?

Posted by on 25 August 2013 - 11:59 PM

There's a major difference between live data (in RAM, workable) and storage data. The concept of serialization is the bridge between the two things and I don't really suggest to even try doing it in a different manner.

Truth is even OOP is a buzzword. Yes, it gave us much more than many other methodologies, but don't take for granted it's the only thing in existance. When sending stuff over the wire (or to storage, for that matter) OOP does not hold much. You must send bits and will get bits, trying to convince yourself otherwise is trying to live in an abstract world. It's just numbers and conventions. The hardware will send you numbers, you will work with numbers. Period.


I think the main fallacy in your line of thinking is to draw a single "databases" block while there are clearly different databases involved. I strongly believe you didn't get the whole point of what OOP is, consider:

i'm sure there are other places where this situation arises as well. I think it stems from the OO vs non-OO way of looking at data.  Apparently, in OO, it not uncommon to take "everything is an object" literally, and to the extreme. To the point where individual records in a database become objects, and perhaps even fields in those records. The result would/could/might be a proliferating tree of objects on the heap. Add in creating and destroying objects on the fly, and you have a constantly changing giant rats-nest tree of objects possibly/probably fragmenting the heap.

The inference OOP-->objects on heap is wrong. OOP itself does not mandate heap usage, much less heavy usage fragmenting the heap.

The point is that you have "blobs" of data which you don't modify directly but use specific functions instead. In many OOP languages, the functions are "near" the data they manipulate. But they don't have to be! OOP is possible in C and even ASM.

#5087228 Correct way to implement a scripting language for game logic.

Posted by on 19 August 2013 - 02:07 AM

Without elaborating your design, it could be ok or not. So let me check if we are on the same mind set. Let's do that easily by considering items first.

Suppose we have:

  1. food - decreases hunger attribute by F
  2. potion - increases health attribute by P

This does not need scripting. Data-oriented design is sufficient.

Enemies are a thougher call. In general, enemies need to have a set of skills which is where scripting comes into play. Personally I would never allow a script to fully define an enemy: there must be a basic set of properties about them. I'd rather allow script callbacks to evaluate its attack logic or skill use.

In my experience, having a generic Update() call to be shared across all entities is a bit fragile in concept. Better to have things such as RunEnemyLogic() or Tick(time) if everything fails. I don't have an Update() call in my system - distributing script processing is left to the script itself.

So the enemies might be:

  1. man { model: "man.mdl";  skillSet="humanSkills.lua";  skillList="hide, evade, attack"; };
  2. goblin { model: "goblin.mdl";  skillSet="gobSkills.lua";  skillList="attack, fury, resistance"; };

Of course in this case you'd have to figure out a way to maintain, for each "skill" loaded and bound to each actor, a way to maintain its state and design all the proper interfaces. Allowing to "just do everything" might make sense but I'm not quite sold on it.

#5086035 General Engine Optimizations

Posted by on 15 August 2013 - 01:30 AM

This has nothing to deal with optimizations. It is architecture. What's really worrying me is that nothing here really maps directly to real world usage. We have some high-level (supposed to be UML?) 10,000ft architecture pictures... awesome. And some nitty gritty details about how the engine manages its input and loop.

Wait, there's something directly mapping to engine usage, it is

//Game Programming
GameStaticObject* playerHouse = new GameStaticObject();
playerHouse->Load("House1"); //done!

There's a lot of trouble here. It's skipping a lot of details... but more importantly is: what about a dynamic object? What about a dynamic object with no collision? The "GameObject" is probably one of the worst inventions in game architectures ever... it's close to be usable when using a component model but this does not appear to be in this mindset. Anyway, at the very last, it should be like

GameStaticObject* playerHouse = new GameStaticObject("House1");

Because this means it would be RAII, which is good. But I am still scared about what you're going to write on the documentation... all functions taking an object will have to be documented with a game object sub-type because of course if GameStaticObject is "everything" then I'd expect to be able to do

GameStaticObject* emitter = new GameStaticObject("crackle.ogg");

As for the performance considerations: I strongly suggest to screw all that!

#5085108 How to implement a Component-Based Entity system?

Posted by on 12 August 2013 - 12:41 AM

I suppose you don't figure out what a component based system is because - as I see it - "component based" is a hot buzzword and everyone on the internet feels completely entitled to write about them, even though they shouldn't.

I think the 1st thing is this article about Mick West. Main point here is the "parallelism" between the components as noted on the pictures.

This gamedev.net article is a bit minimalistic and thus good. Keep in mind that terminology is an issue, let alone model. Regardless of the post count about component systems some fundamental issues appear to go along undiscussed and likely unnoticed.


Take the example above. Component based systems take for granted components are orthogonal to each other so TransformComponent can be manipulated. I dare you to find a physics library allowing you to do that with no repercussions - the above operation is only valid for kinematic objects (in the case of Bullet, it would wreak havok even on kinematics).


In general, what I suggest is to read a minimal amount of things first. Iterate to better understand your problem and then refine your solution, using your data and your (now) deeper problem understanding.  In the end, details are the problem here.

#5081385 GPU particles

Posted by on 29 July 2013 - 02:22 AM

I just want to make a clarification:

Also, on the topic of gpu particles, I've seen some systems that use directcompute instead. Am I correct in assuming that only works on feature level 11 and up?
No. GPU particles have been around for a while, they are viable on anything that is Shader Model 3.0 and later - google "Lutz Latta" and "Building a million particle system". More advanced hardware makes everything much more streamlined and eventually takes it to be viable on a meaningful installed base.