Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Madoc

Member Since 25 Sep 2007
Offline Last Active Nov 21 2012 12:22 PM

Posts I've Made

In Topic: How would you make something like this?

21 November 2012 - 12:07 PM

Elo again,

Pretty busy these days! I'll try to say something but going into any depth here would require a lot of time.

•How many rigid bodies can it currently support (on an average target user machine)?

Honestly we haven't really stress tested it, more than enough for our purposes. Probably in practice the most demanding thing is something that keeps the simulation fluid (no jittering and popping) and stable even when objects are put under impossible stress. Of course most of the time objects are resting and cost nothing.

What is still very demanding is cloth collision detection (you can see this on the cloak here www.youtube.com/watch?v=OPrOonmaG00). That's still going to need some clever optimisation.

•When it comes to importing the meshes to the physics system, are they converted to a low-poly version and fit with convex hulls?

Umm... To be honest this is something I'd rather not reveal while we're still so early in development with the game. We'd like to be able to use it first. I hope you understand.

•Any details you can share about the physics+animation combination would be cool.

Well, applying some forces to an articulated body is not a big deal but all you get is a body twitching awkwardly on the ground. Going from there to something that behaves like a character, that can maintain and recover balance, swing heavy weapons without falling over, get up from having fallen, run over rough terrain and do all sorts of other things is rather challenging. This needed a lot of procedural behaviours and basically a mountain of hacks, and the way it all interacts is the stuff of nightmares. A lot of the body is controlled almost purely procedurally and getting it to behave well in all circumstances has threatened to drive me insane. It's still a bit clumsy but I hope to improve it further, also with more predictive behaviours which have been somewhat neglected so far. I'm also looking to include more hand crafted solutions (i.e. for breaking or preventing a fall) which from the little I've picked up looks to be closer to how Euphoria works.

For some reason I still don't fully understand, I can't get traditional IK solvers to interact well with the system. I've tried this several times and just failed to produce anything that wasn't a bit twitchy (the people who made Euphoria are probably laughing at me right now). I have something that sort of does the job but it works in mysterious ways :).

In Topic: How would you make something like this?

20 November 2012 - 03:30 PM

As a member of the gamedev forums I thought I'd step in here and drop a line.

L. Spiro, you seem to just be describing some constraint solving method. It's not what I use but even so this would amount to a couple of line of codes, our character animation system is currently shy of 15000 lines of code.

Don't want to bash anyone or anything, it doesn't seem right to mislead people into thinking that what I've done here can be reduced to something so simple. It's the result of a really huge effort, lots of testing and tweaking and still it's a work in progress. I usually get things done very quickly, this has taken away inordinate amounts of my time.

Cheers,
Madoc

In Topic: Fast ray casting for AO

02 November 2007 - 08:40 AM


Ugh. Right, well... Let me try and reply to some of that.

Andy,
I understood what you mean from your post earlier today. I see the merit in the method but it just wouldn't work for our models, the depth complexity would cause problems. The only way we could be using something similar is by rendering from inside out and that has the problems I described earlier.

Anyway, as for the precision, we're not really doing AO, I mentioned that before. Accessibility shading is closer to what we are doing, but even that doesn't quite fit. There's a lot of stuff you can do with this information.

You can set your FoV to 90 degrees but our sample hemisphere is half a sphere and covers 180 degrees, hence the requirement for something more like a cubemap.

---

I finished implementing kd Trees. The tree itself gave suriprisingly little improvement over the Octree approach (it should be a fairly decent SAH implementation) but the "neat tricks" mentioned seem very worthwhile, I implemented just one and got a ~250% speed increase in the raycasts. These kd trees have some nice implicit properties.

In Topic: Fast ray casting for AO

01 November 2007 - 01:50 PM


What we're doing is quite different. Strictly speaking, it's not even AO and certainly not the kind of AO you see so much of these days.

We need to sample a complete hemisphere and the only way (I can think of) to do that is with half a cube map as I mentioned above. Also we need very high levels of multisampling. The occlusion is calculated (with MS) for every pixel of very large maps and models are several million polygons. If you stick to the requirements I gave, some of our maps would take over 300 billion renders of several million polys.

It's the specific number of "rays" in Melody that leads me to believe that it uses actual rays, you can't achieve any number of well distributed pixels with an image, but of course they could just be lying about the number...

Hope that clarifies things a litle.

In Topic: Fast ray casting for AO

01 November 2007 - 12:53 PM

That was basically in my reply to _Lopez. But for what we do, we'd need to render 75 images per texel and without some expensive additional work the results would be incorrectly biased. You also have the problem of the near clipping plane (which you can eliminate but not without causing more problems). This has to be precision work.

Edit:

I estimate the GPU rendering path as above would take about a week as opposed to a couple of hours. Also NVidia's Melody allows you to choose a *specific number* of "rays", that suggests rays is indeed what they are using.

kd trees look nice. I haven't found any decent literature but playing with the idea I can see some really neat tricks to speed things up. I'll definitely try it tomorrow.

[Edited by - Madoc on November 1, 2007 7:53:42 PM]

PARTNERS