Scott Brooks | 4 Jan 2007 22:35

Re: Admin Notice: SWENG-GameDev mailing list downtime Tuesday

On Monday 04 December 2006 9:38 pm, Davis Sickmon wrote:
> Howdy all -
>
> Tuesday from 3 PM (PST) to around 6 PM the list will be down for some
> server upgrades.  I apologize for any inconvenience caused by the
> upgrade, and apologize for any increased productivity caused by the
> inability to loaf and chat on the list ;-)
>
> Davis "Midnight Ryder" Sickmon
> Executive Producer, World of Gamer Zone
> All hail King of SWENG-GameDev!
>
> _______________________________________________
> sweng-gamedev mailing list
> sweng-gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Hopefully this 'is the list alive' query works out better then the last one 
that triggered someones autoreply, but I haven't received any e-mails since 
this 'server upgrade' message.

Scott Brooks
_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Richard Fabian | 5 Jan 2007 13:00

Re: Admin Notice: SWENG-GameDev mailing list downtime Tuesday

We all turned our brains off for Christmas :)

On 1/4/07, Scott Brooks <scott <at> hermitworksentertainment.com > wrote:
On Monday 04 December 2006 9:38 pm, Davis Sickmon wrote:
> Howdy all -
>
> Tuesday from 3 PM (PST) to around 6 PM the list will be down for some
> server upgrades.  I apologize for any inconvenience caused by the
> upgrade, and apologize for any increased productivity caused by the
> inability to loaf and chat on the list ;-)
>
> Davis "Midnight Ryder" Sickmon
> Executive Producer, World of Gamer Zone
> All hail King of SWENG-GameDev!
>
> _______________________________________________
> sweng-gamedev mailing list
> sweng-gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Hopefully this 'is the list alive' query works out better then the last one
that triggered someones autoreply, but I haven't received any e-mails since
this 'server upgrade' message.

Scott Brooks
_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com



--
fabs();
Just because the world is full of people that think just like you, doesn't mean the other ones can't be right.
_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Kyle Wilson | 6 Jan 2007 18:49

Re: Granularity and update - RE: strategies/patterns for composition

Oops!  I was just checking my new Sweng-gamedev mail and realized that in 
the crush of holidays, milestone deliverables and business travel last 
month, I never replied to this post from November.  Oh, well, six weeks late 
is better than never, right?

A long time ago, Nick Trout wrote:
> When you say DAG, do you mean list of lists? i.e. system A is (state) 
> dependent on system B,
> so if I add a component which has a dependency on A, I know it must update 
> all of the B
> component data before A?

Our dependency DAG comprises nodes in a graph, each containing a vector of 
parent node pointers and a vector of child node pointers.  All parents must 
update before any of their children can update.  Nodes which aren't dirtied 
during the course of a frame don't get updated at all.

The design was somewhat shaped by 
http://www.gamasutra.com/features/20030829/vanderbeek_01.shtml.  And the 
dependency graph description in the Maya 6.5 API whitepaper 
(http://downloads.alias.com/mkt/gmk_maya_65_api_whitepaper.pdf) might also 
be helpful, though our implementation is pretty different.

> I'm curious: do you think you could specify dependencies at the system 
> level (assuming you
> have a fairly well encapsulated game systems that could be updated 
> sequentially in a fixed order)
> and then do away with the DAG?

I don't think so.  The system arose out of an issue that came up in the 
development of the MechAssault games where we often had game-object 
behaviors that depended on the final position of a bone in the scene 
hierarchy.  (Either we wanted to attach one object to a particular location 
on another or we wanted to emit weapon effects from the final position of a 
weapon at the end of a frame, for example).  Normally we updated all game 
object logic, then all scene hierarchy positions.  But in these cases, we 
ran additional animation and update passes on the objects we cared about so 
that we could sample frame-end bone positions while we were still updating 
game logic.  This was a pretty hacky fix, but it worked, at the cost of a 
millisecond or two of redundant animations and updates.

> Do you think the DAG is necessary because the granularity of the 
> components is too small?

Pretty much.  In our current game, we've switched to a component-based game 
object architecture, and the relationships between objects have become even 
more complicated.  I think that we have a number of circumstances where a 
component from object A depends on a component from object B, which in turn 
depends on another component back in object A.  And the relationships change 
every time a new object is spawned, someone gets into a vehicle, someone 
picks up a weapon, etc.

I'd love to be able to define up front an fixed order for updating 
components of different classes, so I could do away with the DAG and just 
have an explicit, hard-coded update order for all game systems.  But I think 
that would only be feasible in a pretty static game.

> Couldn't you just keep a queue of objects to create (and perhaps delete) 
> whilst the DAG is
> updated and then just wire in the new objects once the DAG update is 
> finished?

I'd also love to be able to do that.  Unfortunately, our gameplay 
programmers were adamant that they needed to be able to spawn new nodes and 
update them in the order in which they're spawned.  We have some systems 
that basically depend on every game object.  For example, there's a single 
"Physics Update" node that depends on all AI/player inputs that might apply 
impulses and is in turn depended on by everything that cares about the final 
positions of objects in a frame.  So when we spawn new objects, we have to 
make sure they spawn and get updated before the physics node updates.

This is a pain, but given the kind of game we're making, I don't see how we 
could get away with deferring all object creation to the next frame or 
requiring objects to be spawned in a proper state without updating.

Regards,
Kyle Wilson
Day 1 Studios

_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Don Gunter | 12 Jan 2007 17:40

Design Practices for game GUI

Hi,

What do ya’ll consider to be the best design practice for implementing UI controls?

-Controls as a separate 2D render and bitmap

-Controls as SceneGraph entities/objects(display at frame rate, update < framerate)

 

The reason I ask is that some data I wish to analyze is only onboard the graphics card and has to be copied back to CPU memory, then sent back when I render.

I was thinking of attempting some controls that monitor splines data and pipeline status as well as for a couple of gizmos.

 

Does anybody have any references on design patterns for game/simulation UI controls implemented onboard the graphics card?

 

Regards,

Don Gunter

_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Will Vale | 13 Jan 2007 23:23
Favicon
Gravatar

Re: Design Practices for game GUI

> Does anybody have any references on design patterns for game/simulation  
> UI
> controls implemented onboard the graphics card?

I've seen some examples (but I forget where - sorry - possible one
of the NVidia SDK samples though?) of on-GPU curve display. When I
implemented something similar for displaying tone curves, I did the
following - but this is more a recipe than a pattern.

* Stick the normalised curve in a 1D texture LUT.

* Draw a rectangle with U and V covering [0,1]x[0,1]

* Per pixel, fetch the curve value and compare to the V coordinate to
   output colour or blackness.

This gives a solid curve, but you can get a thin line (useful for
displaying multiple curves on one graph) by comparing the curve value
to the interval [v, v+one_texel]

HTH,

Will

_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Peter_Hodges | 15 Jan 2007 17:10

Re: Shoot system driven by physics or graphics


How about scene replays in which the camera is oriented differently? If you are recomputing your physics then this could lead to somewhat divergent results.

Peter Hodges
Sony Computer Entertainment Europe
http://www.scee.com



Kris Lamb <sod_lambda <at> hotmail.com>
Sent by: sweng-gamedev-bounces <at> lists.midnightryder.com

15/01/2007 16:02

Please respond to
sweng-gamedev <at> midnightryder.com

To
<sweng-gamedev <at> midnightryder.com>
cc
Subject
Re: [Sweng-gamedev] Shoot system driven by physics or graphics






>>In practical terms, how would you deal with needing to fire a ray at
>>something that wasn't in the view-frustum; maybe it's far enough away so
>>that it's not loaded in yet (as graphics data)? Maybe it's only got a

>If you don't see it you can't hit it... it reasonable, no?

If I shoot, then quickly turn then it doesn't count?  Maybe not the best answer :(  Just one of the considerations for that problem that you might have to overcome.

Be one of the first to try Windows Live Mail._______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com


**********************************************************************

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster <at> scee.net

This footnote also confirms that this email message has been checked for all known viruses.

Sony Computer Entertainment Europe Limited

Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom

Registered in England: 3277793

**********************************************************************

_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Barkley | 15 Jan 2007 17:50

Re: Shoot system driven by physics or graphics

In games, usually, you want that what you see before the cross-hair is what
you actually hit.

The other problems are addressed independently of whether we use visual or
physic meshes. Have in mind that I'm always going to go first to the physic
mesh. If something is not able to be intersected this info is already in the
user data attached to physic model, so I'll never go to the visual mesh for
this purpose.

Have in mind that if you use the physic models to do the shooting raycasts
you will have more complex physic meshes because you need more detail and
you need different objects for different materials (in PhysX you may have
materials per triangle but only for the concave meshes and it may be a bit
tricky). So the complexity of your physic scene may be significantly
affected by this decision, while if you use the visual mesh a building could
be a box.

Another option is having a different model: the collision model. This should
be a simple scene with only collision models that would be very similar to
physic ones but different from them (because of the problems previously
described) and should be updated at a different rate (probably the best,
when needed). But we couldn't use the physic scene because its costly so we
should implement a whole new system which very costly in development time
and would also use some memory (though I don't think it would be a problem).

Barkley

-----Mensaje original-----
De: sweng-gamedev-bounces <at> lists.midnightryder.com
[mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] En nombre de Crosbie
Fitch
Enviado el: lunes, 15 de enero de 2007 16:20
Para: 'sweng-gamedev <at> midnightryder.com'
Asunto: Re: [Sweng-gamedev] Shoot system driven by physics or graphics

> From: Barkley
> This method is also very accurate (what you see is what you hit)

Isn't it "What your gun sees is what it may hit" - given windage, scene
change during bullet travel, etc.?

Walk up to a 5 foot high brick wall, and your handgun may not see what your
eye does.

I appreciate you may be tracing the path from the gun anyway, but just
pointing out how the distinction between hand and eye can easily be
dissolved.

Perhaps in addition to physics and visual models, there should also be a
collision model? Visible is not necessarily collidable. Perhaps mark certain
geometry as non-collidable, and other geometry as non-visible?

And what of the presence of geometry damaged by gunfire, but that has no or
only moderate effect on passage? From paper bags to glass windows.

Ray guns affected differently to projectile weapons, etc. Ricochets vs
absorbtion vs deflection, etc.
_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Megan Fox | 15 Jan 2007 17:14
Picon
Gravatar

Re: Shoot system driven by physics or graphics

> >>In practical terms, how would you deal with needing to fire a ray at
> >>something that wasn't in the view-frustum; maybe it's far enough away so
> >>that it's not loaded in yet (as graphics data)? Maybe it's only got a
>
> >If you don't see it you can't hit it... it reasonable, no?
>
>  If I shoot, then quickly turn then it doesn't count?  Maybe not the best
> answer :(  Just one of the considerations for that problem that you might
> have to overcome.

It's a very reasonable answer.  I mean, even if you could assure that
it was only possible for the player to shoot at things he or she could
see, that same firing system is probably used for NPCs - if an NPC
ever had to shoot at another NPC, there's a very, very good chance
that one or both wouldn't be visible at the time.

I'd agree with the lead as well.  Shooting is a physical operation,
and should rely on physical data.  If you're using ragdoll data and
don't want to keep ragdolls around for everything to bog the physical
world down, then you've got to make a second level to the system that
keeps each currently-unused ragdoll in a space that can be queried.
So instead of querying to the visible data, you just query out to a
different physical space that contains the animating ragdoll.

(or - more tradtionally - you just don't use a ragdoll, and instead
use some level of hitbox calc)

--

-- 
-Megan Fox
Idyllon, LLC
http://shalinor.circustent.us/megan/resume/
_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Andrew Vidler | 15 Jan 2007 16:49

Re: Shoot system driven by physics or graphics

Hi,
 
I can't imagine how you'd do that efficiently. :)
On PC you'd maybe be able to do that on some graphics cards - but then what do you do with the users that haven't got the latest and greatest cards?
On consoles - maybe - but I'd say that it'd still be slow and if you have that kind of gpu processing spare then surely you'd rather have better graphics rather than the ability to shoot someone in the fingernail rather than their arm?
 
Also, granted, the data transfer may be minimal, but how would you synchronise the result? The GPU and CPU won't (in general) be running in lock-step so you've no good way of knowing (from the CPU point of view) when the data is valid or not - what happens if the GPU is a few frames out of sync' with the CPU?
 
Even if you could make all these problems go away and make the GPU cost small you'd still (presumably) have to issue a set of draw calls for each ray you wanted to shoot which would increase your CPU overhead again (less on consoles, admittedly).
 
Just seems waaaaay more trouble than it's worth to me. :)
 
Cheers,
Andrew.

From: sweng-gamedev-bounces <at> lists.midnightryder.com [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Alistair Milne
Sent: 15 January 2007 15:31
To: sweng-gamedev <at> midnightryder.com; andrew.vidler <at> ninjatheory.com
Subject: Re: [Sweng-gamedev] Shoot system driven by physics or graphics

"Running any kind of ray-trace through a model's triangle mesh when that
tri-mesh is somewhere like (for example) VRAM is going to be horribly slow."

Not necessarily, if the graphics hardware is sufficiently programmable then such a raytrace can be requested from the CPU, performed on the GPU, and then the result passed back across the divide.  Minimal transfer of data required.



On 1/15/07, Andrew Vidler <andrew.vidler <at> ninjatheory.com> wrote:
Hi,

You need to be careful about *where* in memory your graphics and physics
data are stored. On a lot of platforms graphics data is stored in areas of
memory that will be very slow to access from the main cpu while main-memory
will be relatively slow to access from the gpu.

Running any kind of ray-trace through a model's triangle mesh when that
tri-mesh is somewhere like (for example) VRAM is going to be horribly slow.

When you say "the detailed info' is too heavy to be loaded in the physics",
I assume you mean you can't load a tri-mesh for each character as it'd take
up too much memory. While this may well be true, there are two things to
keep in mind:
1) You don't need a separate tri-mesh instance for each character
(presumably they aren't all distinct character meshes) - you can instance
the data.
And:
2) You probably don't want to use a tri-mesh at all - surely a collection of
capsules would do just as well and work fast plus take up less memory?
(Again, these can be instanced if you need to).

In terms of performance - just make the collision use a single capsule if
the character is over a certain distance away; no-one will notice.

There's also the question of separation of code - you don't really want to
have dependencies between physics and rendering if you can help it.

In practical terms, how would you deal with needing to fire a ray at
something that wasn't in the view-frustum; maybe it's far enough away so
that it's not loaded in yet (as graphics data)? Maybe it's only got a
low-lod representation at the moment? You may be able to ignore of all these
things currently, but you never know what might change in the future and by
coupling the physics ray-shooting to the rendering you're opening up all of
these questions across both systems and making them both far more complex
than they need to be.

I'm not saying that you're system is wrong in any way - just that these are
all things you're probably going to have to explain and justify to your lead
before he'll relent! :)

HTH,
Cheers,
Andrew.

> -----Original Message-----
> From: sweng-gamedev-bounces <at> lists.midnightryder.com
> [mailto: sweng-gamedev-bounces <at> lists.midnightryder.com] On
> Behalf Of Barkley
> Sent: 15 January 2007 10:55
> To: sweng-gamedev <at> midnightryder.com
> Subject: Re: [Sweng-gamedev] Shoot system driven by physics
> or graphics
>
> There is no networking in the game. Is a single player FPS.
>
> The detailed information is too heavy to be loaded in the
> physics. Also, having objects in a scene even slept without
> gravity and no collisions consumes CPU (we are using Ageia's
> engine). So it's not mainly a memory problem but a
> performance problem. You want to have 100 characters and you
> want it to have a smooth frame rate. And the characters have
> skinning so you have to update them (at least) every time you
> shoot to the physics. It's quite time consuming from my point of view.
>
> Barkley
>
>
> -----Mensaje original-----
> De: sweng-gamedev-bounces <at> lists.midnightryder.com
> [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com ] En
> nombre de Hedberg, Mikael Enviado el: lunes, 15 de enero de 2007 10:35
> Para: sweng-gamedev <at> midnightryder.com
> Asunto: Re: [Sweng-gamedev] Shoot system driven by physics or graphics
>
> What kind of game is this?
>
> Consider a multiplayer game, and the issue of standalone
> servers, lag, server vs client knowledge, and such things. I
> really do agree with your lead on this - rendering system
> knowledge should not be used for physics. It's a question of
> dependencies really... You should be able to run your physics
> with rendering switched off and no rendering data loaded.
>
> If you need the detailed mesh information in the physics
> system, make sure that data is known by the physics system
> proper (you can always use reference counting or whatever to
> share the mesh data between systems to save memory).
>
> Regards,
> Mikael
>
> -----Original Message-----
> From: sweng-gamedev-bounces <at> lists.midnightryder.com
> [mailto: sweng-gamedev-bounces <at> lists.midnightryder.com] On
> Behalf Of Barkley
> Sent: den 15 januari 2007 10:09
> To: sweng-gamedev <at> midnightryder.com
> Subject: [Sweng-gamedev] Shoot system driven by physics or graphics
>
> Hi all,
>
> I've recently had a discussion with my lead regarding to
> where the shoot system should finally look for a hit. I'm the
> physics programmer and I have developed a system I call
> "accurate raytracing" that looks in the physics scene for all
> the hits of a ray and then sorts them from the nearest to
> furthest, and finally looks into the visual meshes associated
> to those physic objects for a real hit, stopping as soon as a
> hit is found. This method is reasonably fast (it can be
> queried several times per logic tick without sensible penalty
> on the performance). This method is also very accurate (what
> you see is what you hit) and, from my point of view the most
> suitable for the shooting system.
>
> On the other hand, he says that the visual system should
> never be queried for a "logic" task (shooting is a logic task
> in his opinion).
> That mixing both systems could lead to unexpected errors. He
> proposes to have the physic always being the one to look at
> when you shoot. That means having "accurate"
> models for all the characters in the scene (we want to have
> about 100 civilians plus the enemies in scene) instead of
> only the character controllers. Besides the unability of
> having 100 complete ragdolls on scene at the same time, and
> the time consuming in updating them, I really see no
> necessity in doing it.
>
> He argues that if there is a necessity of post-processing or
> cheating with the shooting system you cannot do anything on
> the rendering system.
> I say that you have a previous phase where you go through the
> physic scene and you can do there what you want.
>
> I really see no other possible problem in using the visual
> engine to do the accurate raycasting queries. I'd like you to
> comment your opinions/experiences to this subject because
> that's the first shooter I'm working on (and so my lead) and
> I may be missing some possible issues.
>
> Thanks in advance,
>
> Barkley
>
> _______________________________________________
> sweng-gamedev mailing list
> sweng-gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midn
> ightryder.
> com
> _______________________________________________
> sweng-gamedev mailing list
> sweng-gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midn
> ightryder.com
>
> _______________________________________________
> sweng-gamedev mailing list
> sweng-gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midn
> ightryder.com
>


_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Kris Lamb | 15 Jan 2007 16:14
Picon
Favicon

Re: Shoot system driven by physics or graphics

That's pretty much what my train of thought is.  It sounds like you already have a solution that works, tell your boss why your solution is good and make sure to bring up that a) it works b) a re-write is going to cost a lot of time/money.




From: Barkley <at> pyrostudios.com
To: sweng-gamedev <at> midnightryder.com
Date: Mon, 15 Jan 2007 16:01:56 +0100
Subject: Re: [Sweng-gamedev] Shoot system driven by physics or graphics

.ExternalClass .EC_shape {;} .ExternalClass EC_p.MsoNormal, .ExternalClass EC_li.MsoNormal, .ExternalClass EC_div.MsoNormal {margin-bottom:.0001pt;font-size:12.0pt;font-family:'Times New Roman';} .ExternalClass EC_a:link, .ExternalClass EC_span.MsoHyperlink {color:blue;text-decoration:underline;} .ExternalClass EC_a:visited, .ExternalClass EC_span.MsoHyperlinkFollowed {color:blue;text-decoration:underline;} .ExternalClass p {margin-bottom:.0001pt;font-size:12.0pt;font-family:'Times New Roman';} .ExternalClass EC_span.EstiloCorreo18 {font-family:Arial;color:navy;} <at> page Section1 {size:595.3pt 841.9pt;} .ExternalClass EC_div.Section1 {page:Section1;}

So, you are saying that I should be able to gain access to the visual data or the physic data. My proposed model uses more or less this idea: the graphic engine has some functions that allow you to raycast against the visual meshes, updated with the last skinning (which was done in the last render). I’m using this function not waiting for the renderer to tell me anything. In fact, the geometry is already optimized to do this kind of tests. So I’m using the visual data with the last update done in the last render, but not the renderer itself. Is it what you mean?

 

 You say: Is it not possible to gain access to the data within the physics engine, so essentially doing the same thing, just not within the renderer? I guess you mean the visual engine, no?

 

Barkley

 

De: sweng-gamedev-bounces <at> lists.midnightryder.com [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] En nombre de Kris Lamb
Enviado el: lunes, 15 de enero de 2007 15:49
Para: sweng-gamedev <at> midnightryder.com
Asunto: Re: [Sweng-gamedev] Shoot system driven by physics or graphics

 

If I understand your problem correctly, you're saying you want to do an approximation in the physics system to notify the graphics system of close encounters and have it use the visual meshes to get actual hits.  Is it not possible to gain access to the data within the physics engine, so essentially doing the same thing, just not within the renderer?  If your current system doesn't have access to the data in other modules, you could easily change it to have references to objects.
 
I think the big problem people would have with your idea is that collisions are physics not graphics, so keep it in the physics engine, but obviously if you want to know if a bullet hit a characters finger you need to know the model data, which means you'll have to at some point share the information.



> From: Barkley <at> pyrostudios.com
> To: sweng-gamedev <at> midnightryder.com
> Date: Mon, 15 Jan 2007 11:55:12 +0100
> Subject: Re: [Sweng-gamedev] Shoot system driven by physics or graphics
>
> There is no networking in the game. Is a single player FPS.
>
> The detailed information is too heavy to be loaded in the physics. Also,
> having objects in a scene even slept without gravity and no collisions
> consumes CPU (we are using Ageia's engine). So it's not mainly a memory
> problem but a performance problem. You want to have 100 characters and you
> want it to have a smooth frame rate. And the characters have skinning so you
> have to update them (at least) every time you shoot to the physics. It's
> quite time consuming from my point of view.
>
> Barkley
>
>
> -----Mensaje original-----
> De: sweng-gamedev-bounces <at> lists.midnightryder.com
> [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] En nombre de Hedberg,
> Mikael
> Enviado el: lunes, 15 de enero de 2007 10:35
> Para: sweng-gamedev <at> midnightryder.com
> Asunto: Re: [Sweng-gamedev] Shoot system driven by physics or graphics
>
> What kind of game is this?
>
> Consider a multiplayer game, and the issue of standalone servers, lag,
> server vs client knowledge, and such things. I really do agree with your
> lead on this - rendering system knowledge should not be used for
> physics. It's a question of dependencies really... You should be able to
> run your physics with rendering switched off and no rendering data
> loaded.
>
> If you need the detailed mesh information in the physics system, make
> sure that data is known by the physics system proper (you can always use
> reference counting or whatever to share the mesh data between systems to
> save memory).
>
> Regards,
> Mikael
>
> -----Original Message-----
> From: sweng-gamedev-bounces <at> lists.midnightryder.com
> [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of
> Barkley
> Sent: den 15 januari 2007 10:09
> To: sweng-gamedev <at> midnightryder.com
> Subject: [Sweng-gamedev] Shoot system driven by physics or graphics
>
> Hi all,
>
> I've recently had a discussion with my lead regarding to where the shoot
> system should finally look for a hit. I'm the physics programmer and I
> have developed a system I call "accurate raytracing" that looks in the
> physics scene for all the hits of a ray and then sorts them from the
> nearest to furthest, and finally looks into the visual meshes associated
> to those physic objects for a real hit, stopping as soon as a hit is
> found. This method is reasonably fast (it can be queried several times
> per logic tick without sensible penalty on the performance). This method
> is also very accurate (what you see is what you hit) and, from my point
> of view the most suitable for the shooting system.
>
> On the other hand, he says that the visual system should never be
> queried for a "logic" task (shooting is a logic task in his opinion).
> That mixing both systems could lead to unexpected errors. He proposes to
> have the physic always being the one to look at when you shoot. That
> means having "accurate"
> models for all the characters in the scene (we want to have about 100
> civilians plus the enemies in scene) instead of only the character
> controllers. Besides the unability of having 100 complete ragdolls on
> scene at the same time, and the time consuming in updating them, I
> really see no necessity in doing it.
>
> He argues that if there is a necessity of post-processing or cheating
> with the shooting system you cannot do anything on the rendering system.
> I say that you have a previous phase where you go through the physic
> scene and you can do there what you want.
>
> I really see no other possible problem in using the visual engine to do
> the accurate raycasting queries. I'd like you to comment your
> opinions/experiences to this subject because that's the first shooter
> I'm working on (and so my lead) and I may be missing some possible
> issues.
>
> Thanks in advance,
>
> Barkley
>
> _______________________________________________
> sweng-gamedev mailing list
> sweng-gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.
> com
> _______________________________________________
> sweng-gamedev mailing list
> sweng-gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
> _______________________________________________
> sweng-gamedev mailing list
> sweng-gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Be one of the first to try Windows Live Mail.


Be one of the first to try Windows Live Mail.
_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Gmane