Client Only Effects. Best Approach?
by Phil Carlisle · in Torque Game Engine · 04/27/2002 (3:48 pm) · 24 replies
Ok, I need to look at some client only effects. That is, things that ONLY reside on the client.
Whats the best way to structure this?
Ive not noticed a nice class that does anything specifically client side.
Whats it for?
Lots of idea.. first one is grass.
I want to draw a load of billboarded grass quads near the player, but this is entirely client side.
So, anyone suggest a good scheme/class to derive from?
Phil.
Whats the best way to structure this?
Ive not noticed a nice class that does anything specifically client side.
Whats it for?
Lots of idea.. first one is grass.
I want to draw a load of billboarded grass quads near the player, but this is entirely client side.
So, anyone suggest a good scheme/class to derive from?
Phil.
About the author
Recent Threads
#2
.. is this the sort of thing you mean ?
04/27/2002 (5:38 pm)
Phil, this elephant grass was done using Milkshape: 1 triangle per billboard image. It was placed with Melv May's fxReplicator, with the "interactions" switch turned off, which means there are no interactions with the server after placed. There are 3500 tufts of grass in a 150x 150 metre area ..... is this the sort of thing you mean ?
#3
If you turn off "Interactions" as Ken pointed out, the objects are not created server-side. If you turn this off and you don't want collisions to occur then I believe you must configure no collision box during modelling (I'm not an expert here) or place the objects out of the players reach. The second was my initial intention hence calling the setting "Interactions". I thought you could use it for road-side eye-fodder. The only warning is that if the objects are collidable, you've got interactions off and you collide with them then you may get bizarre paradoxes due to the client-side prediction routine arguing with the server-side simulation.
There are many improvements that could be made to this but I was waiting to see how/if people used it.
- Melv.
04/27/2002 (7:04 pm)
It also means that the number of objects replicated is independent of the network traffic e.g. the only initial network traffic is the settings for the fxReplicator itself, nothing for the objects, these are created based upon a seed value only and so you won't get the painfully slow "*** Phase 2: Download Ghost Objects"!If you turn off "Interactions" as Ken pointed out, the objects are not created server-side. If you turn this off and you don't want collisions to occur then I believe you must configure no collision box during modelling (I'm not an expert here) or place the objects out of the players reach. The second was my initial intention hence calling the setting "Interactions". I thought you could use it for road-side eye-fodder. The only warning is that if the objects are collidable, you've got interactions off and you collide with them then you may get bizarre paradoxes due to the client-side prediction routine arguing with the server-side simulation.
There are many improvements that could be made to this but I was waiting to see how/if people used it.
- Melv.
#4
Audio emitters is something I wish it supported. Also straight lines & poly lines. Oh yes, and random or cycled (or both) object selection...
04/27/2002 (9:59 pm)
I use it a lot, Melv. I've had over 65,000 objects placed in TubettiWorld, by using only around 200 fxReplicator objects. Mostly grass, shrubs & a dozen different types of trees - oh yeah and a few static herds of sheep & cattle ...Audio emitters is something I wish it supported. Also straight lines & poly lines. Oh yes, and random or cycled (or both) object selection...
#6
Basically, if you imagine your thousands of tufts all being localised around the player. As the player moves, the only tufts drawn are around the player, with an alpha ramp off as they get further away. So effectively instead of having a replicator which places thousands of them on the level, theyre only placed local to the player. (The replicator I'd use for something like tree's, but not in its current form for the grass).
Thing is, for grass, no-one other than the client needs to see it. Its stricltly a client side eye candy effect, which would be quite nice, but should be a menu choice so that it doesnt slow everyone down.
Your 10FPS is just too slow for most games. :))
The grass effect I'm talking about is being used quite a lot now, games like Serious Sam, Unreal2, SOF2 use it. If you want to see it in action, try getting XIsle demo from nvidia.
Phil.
04/28/2002 (3:12 am)
Ken, thats the look I am talking about, but the mechanics are slightly different.Basically, if you imagine your thousands of tufts all being localised around the player. As the player moves, the only tufts drawn are around the player, with an alpha ramp off as they get further away. So effectively instead of having a replicator which places thousands of them on the level, theyre only placed local to the player. (The replicator I'd use for something like tree's, but not in its current form for the grass).
Thing is, for grass, no-one other than the client needs to see it. Its stricltly a client side eye candy effect, which would be quite nice, but should be a menu choice so that it doesnt slow everyone down.
Your 10FPS is just too slow for most games. :))
The grass effect I'm talking about is being used quite a lot now, games like Serious Sam, Unreal2, SOF2 use it. If you want to see it in action, try getting XIsle demo from nvidia.
Phil.
#7
I just wanted to add something to this.
You say that "only" the client need to see it.
Imaging a sniper laying on top of a small hill hiding in the 2 foot tall grass. Nice camoflauged and perfectly hidden.
The rest of the players on the server however can se him just fine as the grass around him is "only" on his computer. This mean he will be hiding in grass thats not there.
Other that that is sounds like a great idea.
// Clocks out
04/28/2002 (4:24 am)
@ PhilI just wanted to add something to this.
You say that "only" the client need to see it.
Imaging a sniper laying on top of a small hill hiding in the 2 foot tall grass. Nice camoflauged and perfectly hidden.
The rest of the players on the server however can se him just fine as the grass around him is "only" on his computer. This mean he will be hiding in grass thats not there.
Other that that is sounds like a great idea.
// Clocks out
#8
Possibly have a ghillie suit on/off switch, or have him camouflage when prone.
One of the other issues with this approach is that it kind of requires some sort of value in the terrain to say how "grassy" it is. But the overall idea is sound.
There are other effects I'm thinking of client side too though, things that only really should be visible on the client.
Ive still got no idea how best to approach it though. There doesnt seem to be a single "client only" class mechanism I can find.
Phil.
04/28/2002 (5:28 am)
Yeah, thats true Karsten, If I were going to do a sniper in this case, I'd have some server side flags to say that the sniper is in cover too.Possibly have a ghillie suit on/off switch, or have him camouflage when prone.
One of the other issues with this approach is that it kind of requires some sort of value in the terrain to say how "grassy" it is. But the overall idea is sound.
There are other effects I'm thinking of client side too though, things that only really should be visible on the client.
Ive still got no idea how best to approach it though. There doesnt seem to be a single "client only" class mechanism I can find.
Phil.
#9
I was looking at Ken's elephant grass and another possible problem jumped to mind.
If this tall grass bitmap is billboarded then it would mean that it would face the camera even when you are flying a plane above it, looking down. This would make the tall grass lay down on the ground instead of pointing up from teh ground.
This would of course look even badded (word?) if using BB trees.
So a possible solution could be to rescrict the billboarding to the .dts's z-axis. This way it would still be facing teh camera but still be in an upright possition when see from a steep angle.
Would this be doable?
// Clocks out
04/28/2002 (5:58 am)
One more thought :)I was looking at Ken's elephant grass and another possible problem jumped to mind.
If this tall grass bitmap is billboarded then it would mean that it would face the camera even when you are flying a plane above it, looking down. This would make the tall grass lay down on the ground instead of pointing up from teh ground.
This would of course look even badded (word?) if using BB trees.
So a possible solution could be to rescrict the billboarding to the .dts's z-axis. This way it would still be facing teh camera but still be in an upright possition when see from a steep angle.
Would this be doable?
// Clocks out
#10
I see where you're going with this.
If you could elaborate on what exactly you require, I would be more than happy to work on it as a side project.
Let me see if I understand the problems involved correctly by putting a few questions in the bag...
- What causes massively replicated objects to slow the system down? Scoping? Collision Detection? Rendering LOD? Initial creation of huge volumes of objects client-side?
- Do the network scoping mechanism/collisions detection routines not cull these objects based upon the current frustum? If not, why not?
- If we were to implement a dynamic replicator that tracked the current controlling object, would something like a seeded scatter-field be appropriate e.g. positions of replicated objects are dynamically moved each frame according to standard seeding rules in fxReplicator based upon a seed value merged with absolute terrain position? (This would mean you would always get the same objects everytime on each client and could solve Karstens problem). We would need to access the terrain height-map directly as collision detection would be sloooow! Difficult then to use exclusion rules for placement, we could pre-calculate an exclusion map at design time based upon exclusion rules and multiplex the height-field e.g. each position would be flagged as excluded or be a height-value. You could also encode terrain type e.g. desert/forest/swamp to control the object-types to be replicated.
- Would this be for non-collidable objects only? I guess so.
Just a few thoughts for the pot. :)
- Melv.
04/28/2002 (6:04 am)
Phil,I see where you're going with this.
If you could elaborate on what exactly you require, I would be more than happy to work on it as a side project.
Let me see if I understand the problems involved correctly by putting a few questions in the bag...
- What causes massively replicated objects to slow the system down? Scoping? Collision Detection? Rendering LOD? Initial creation of huge volumes of objects client-side?
- Do the network scoping mechanism/collisions detection routines not cull these objects based upon the current frustum? If not, why not?
- If we were to implement a dynamic replicator that tracked the current controlling object, would something like a seeded scatter-field be appropriate e.g. positions of replicated objects are dynamically moved each frame according to standard seeding rules in fxReplicator based upon a seed value merged with absolute terrain position? (This would mean you would always get the same objects everytime on each client and could solve Karstens problem). We would need to access the terrain height-map directly as collision detection would be sloooow! Difficult then to use exclusion rules for placement, we could pre-calculate an exclusion map at design time based upon exclusion rules and multiplex the height-field e.g. each position would be flagged as excluded or be a height-value. You could also encode terrain type e.g. desert/forest/swamp to control the object-types to be replicated.
- Would this be for non-collidable objects only? I guess so.
Just a few thoughts for the pot. :)
- Melv.
#11
04/28/2002 (6:31 am)
Phil, valid point about the frame rate - although I'm not ignoring the FPS, I'm not worrying too much about it right now; the test system is an 800Mhz with GeForce 2 32MB. I'm leaving it up to the BETA testers to complain about the FPS first... :-)
#12
However, if it is an issue, you can use the original kind where the object is always vertical with respect to the Z axis.
04/28/2002 (6:39 am)
Karsten - there are two kinds of billboards - standard ones that maintain their Z axis alignment while always facing the camera, and the BillboardZ types that always face the camera, even when it is above the object. I'm using the latter, and we have flying vehicles. Visually there is only minor anomolous appearance, since the down-view angle is typically about 45 degrees or less. Rarely do you ever look straight down or within 20 degrees of straight down. Second, the distance shrinks the object size enough that, combined with the fairly shallow view angles, the billboardZ effect is not really noticeable.However, if it is an issue, you can use the original kind where the object is always vertical with respect to the Z axis.
#13
OK, I didnt know that the BB already did restrict the z-axis. That's very cool.
/me go play with BB.
// Clocks out
04/28/2002 (6:50 am)
@KenOK, I didnt know that the BB already did restrict the z-axis. That's very cool.
/me go play with BB.
// Clocks out
#14
Thanks Melv, I'd like to see how to handle this myself. Mainly just what sort of class heirarchy to use and exactly where it fits in the engine, even if not the absolute implementation.
Mainly, its simply handling a lot of similar objects as seperate entities. Ideally they need to be handled and drawn as a single object (preferably as tri-strips, but basically, the overhead is there as soon as you create individual elements of any number). This is especially true if they need to be handled by the network layers.
Anything done on a per object basis where there are thousands of objects is best done as a single entity (i.e. particle system).
The sheer volume of objects is just too much, culling still has to do several tests per object. Even with hardware occlusion tests on the GF4 its not going to be efficient. Collision is even worse.
This is pretty much how I intended it to work. Track the client, around the client have a grasss "zone" that drew the grass around it (alpha blended in at the edges). It would need a test for heights, which might be slow, but its only a one time test per new object, and in general most objects will stay in the grass zone for a fair amount of time (almost like a tile based scroller).
[qoute]
Difficult then to use exclusion rules for placement, we could pre-calculate an exclusion map at design time based upon exclusion rules and multiplex the height-field e.g. each position would be flagged as excluded or be a height-value. You could also encode terrain type e.g. desert/forest/swamp to control the object-types to be replicated.
[/quote]
Exactly, have an encoded value that described thickness or type of vegetation. As you near buildings, you simply lower that value.
One thing I'm really interested in doing for this is to try and generate jungle densities with slightly larger billboards. Grass is subtle, but there's not reason this couldnt work well for jungle canopy.
Absolutely. You could apply some LOD in a very small zone within the main grass zone that would implement collision for only the very nearest objects (so you could move leaves aside for instance). But I'm not sure its necassary.
Just a few thoughts for the pot. :)
Good points Melv. I think this is one of those things Ive been seeing in games lately that uses hardware and actually enhances the effect if done well.
Phil.
04/28/2002 (10:42 am)
Quote:
Phil,
I see where you're going with this.
If you could elaborate on what exactly you require, I would be more than happy to work on it as a side project.
Thanks Melv, I'd like to see how to handle this myself. Mainly just what sort of class heirarchy to use and exactly where it fits in the engine, even if not the absolute implementation.
Quote:
Let me see if I understand the problems involved correctly by putting a few questions in the bag...
- What causes massively replicated objects to slow the system down? Scoping? Collision Detection? Rendering LOD? Initial creation of huge volumes of objects client-side?
Mainly, its simply handling a lot of similar objects as seperate entities. Ideally they need to be handled and drawn as a single object (preferably as tri-strips, but basically, the overhead is there as soon as you create individual elements of any number). This is especially true if they need to be handled by the network layers.
Anything done on a per object basis where there are thousands of objects is best done as a single entity (i.e. particle system).
Quote:
- Do the network scoping mechanism/collisions detection routines not cull these objects based upon the current frustum? If not, why not?
The sheer volume of objects is just too much, culling still has to do several tests per object. Even with hardware occlusion tests on the GF4 its not going to be efficient. Collision is even worse.
Quote:
- If we were to implement a dynamic replicator that tracked the current controlling object, would something like a seeded scatter-field be appropriate e.g. positions of replicated objects are dynamically moved each frame according to standard seeding rules in fxReplicator based upon a seed value merged with absolute terrain position? (This would mean you would always get the same objects everytime on each client and could solve Karstens problem). We would need to access the terrain height-map directly as collision detection would be sloooow!
This is pretty much how I intended it to work. Track the client, around the client have a grasss "zone" that drew the grass around it (alpha blended in at the edges). It would need a test for heights, which might be slow, but its only a one time test per new object, and in general most objects will stay in the grass zone for a fair amount of time (almost like a tile based scroller).
[qoute]
Difficult then to use exclusion rules for placement, we could pre-calculate an exclusion map at design time based upon exclusion rules and multiplex the height-field e.g. each position would be flagged as excluded or be a height-value. You could also encode terrain type e.g. desert/forest/swamp to control the object-types to be replicated.
[/quote]
Exactly, have an encoded value that described thickness or type of vegetation. As you near buildings, you simply lower that value.
One thing I'm really interested in doing for this is to try and generate jungle densities with slightly larger billboards. Grass is subtle, but there's not reason this couldnt work well for jungle canopy.
Quote:
- Would this be for non-collidable objects only? I guess so.
Absolutely. You could apply some LOD in a very small zone within the main grass zone that would implement collision for only the very nearest objects (so you could move leaves aside for instance). But I'm not sure its necassary.
Just a few thoughts for the pot. :)
Good points Melv. I think this is one of those things Ive been seeing in games lately that uses hardware and actually enhances the effect if done well.
Phil.
#15
I find this quite interesting so if you need anything then just drop me an email.
All the best,
Melv.
04/28/2002 (11:03 am)
Phil,I find this quite interesting so if you need anything then just drop me an email.
All the best,
Melv.
#16
Ive no problem in drawing the grass. I can work out how to get the heights etc.. but its basically down to where in the present engine structure this sort of thing would fit.
Its not gamebase... no networking.
Or is it? would it be ok as a non ghosted gamebase?
I'm just still not sure how things work internally in the class structure. Ive spent too much time playing with the script.
Phil.
04/28/2002 (11:24 am)
Just some suggestions on the right class to start with I guess Melv.Ive no problem in drawing the grass. I can work out how to get the heights etc.. but its basically down to where in the present engine structure this sort of thing would fit.
Its not gamebase... no networking.
Or is it? would it be ok as a non ghosted gamebase?
I'm just still not sure how things work internally in the class structure. Ive spent too much time playing with the script.
Phil.
#17
I guess it depends on a few things.
If you want the object to be able to render WITHIN the scene then you've got two choices. The first is to plug into an existing rendering object e.g. the 'Player' class. The second is to create your own which means you're going to have to inherit from at least 'SceneObject' which does come from the 'NetObject' but you can get around this like I did with the fxReplicator. If-fact you will have it easier as you want to create your object from scratch whereas I was trying to bend the TSStatic without breaking it.
The reason you need SceneObject is that you need to queue your rendering within the client scenegraph.
To quote Tim Gift from the 'Snapshot Gallery' on my fxReplicator posting:
Perhaps we should ask Tim on his thoughts here?
- Melv.
04/28/2002 (12:02 pm)
Phil,I guess it depends on a few things.
If you want the object to be able to render WITHIN the scene then you've got two choices. The first is to plug into an existing rendering object e.g. the 'Player' class. The second is to create your own which means you're going to have to inherit from at least 'SceneObject' which does come from the 'NetObject' but you can get around this like I did with the fxReplicator. If-fact you will have it easier as you want to create your object from scratch whereas I was trying to bend the TSStatic without breaking it.
The reason you need SceneObject is that you need to queue your rendering within the client scenegraph.
To quote Tim Gift from the 'Snapshot Gallery' on my fxReplicator posting:
Quote:Tim Gift (Mar 17, 2002 at 17:32 GMT)
Very cool :) Setting/clear the ghost flags is a little "hacky", but I guess it works :) At some point it might be nice have a non-networked version of the tsStatic class, or change it to operate cleanly in both modes.
Perhaps we should ask Tim on his thoughts here?
- Melv.
#18
I was thinking of something like this. A "BaseEffect" class, which can either be client side only, or can be server ghosted. So I suppose the ghosting hack would be ok there.
I wanted to use this base class so that it can be "attached" to any object derived from gamebase say, and add effects to it.
There are a load of fairly nice effects I'd like to play with, without all of the baggage involved with most of the other classes. I like the abillity to just attack one effect to another object (so for instance, have a glowing ball effect which could be attached to a player for a shield, or a trigger to note where it is or whatever.
Having a fairly lightweight class which can be used to test rendering tweaks is just a good thing I think.
So something derived from sceneobject is about as low as you think I should go in the class heirarchy?
Phil.
04/28/2002 (2:12 pm)
Melv.I was thinking of something like this. A "BaseEffect" class, which can either be client side only, or can be server ghosted. So I suppose the ghosting hack would be ok there.
I wanted to use this base class so that it can be "attached" to any object derived from gamebase say, and add effects to it.
There are a load of fairly nice effects I'd like to play with, without all of the baggage involved with most of the other classes. I like the abillity to just attack one effect to another object (so for instance, have a glowing ball effect which could be attached to a player for a shield, or a trigger to note where it is or whatever.
Having a fairly lightweight class which can be used to test rendering tweaks is just a good thing I think.
So something derived from sceneobject is about as low as you think I should go in the class heirarchy?
Phil.
#19
I think you're gonna have to inherit from SceneObject if you want to render in the SceneGraph pipe. You're gonna want to use GameBase if you want DataBlock support and interpolate your effects over time (although you can interpolate it yourself using game time).
I grant you that these are not the lightest classes in the world but I just don't see how you can render within the scene without going through the scenegraph.
Possibly, the only other way I can see is to use your own base-class and amend the ShapeBase class to allow a vector of BaseEffects to be contained within it. You can then amend the particular ShapeBase-derived class e.g. Player or Vehicles' 'renderObject' routines to call your render effects procedure (in ShapeBase). This is kinda restrictive in the sense that you need to amend existing ShapeBase-derived classes to make a call to render your effects.
Melv.
04/29/2002 (12:44 am)
Phil,I think you're gonna have to inherit from SceneObject if you want to render in the SceneGraph pipe. You're gonna want to use GameBase if you want DataBlock support and interpolate your effects over time (although you can interpolate it yourself using game time).
I grant you that these are not the lightest classes in the world but I just don't see how you can render within the scene without going through the scenegraph.
Possibly, the only other way I can see is to use your own base-class and amend the ShapeBase class to allow a vector of BaseEffects to be contained within it. You can then amend the particular ShapeBase-derived class e.g. Player or Vehicles' 'renderObject' routines to call your render effects procedure (in ShapeBase). This is kinda restrictive in the sense that you need to amend existing ShapeBase-derived classes to make a call to render your effects.
Melv.
#20
I like the idea of putting a vector of BaseEffects into shapebase, because Ive been doing this for pathing.
I guess then the effect could activate shader changes on the shape which would be kinda nice.
I guess its not hugely lightweight, but seeing as its "built in" to another fairly comprehensive class, I'm not sure its that bad. If you look at things like SetCloaked (which obviously this would be a candidate for a BaseEffect derived effect).
I guess I'll give it a try, see if it causes any problems.
Still doesnt give any hints to say "client side only". Unless I build that into the effect with "IsClient" or something.
Food for thought.
Phil.
Phil.
04/29/2002 (1:46 am)
Hmm.. almost 75% of the effects I'm thinking of could be done using a shader in the TSShapeInstance class. I like the idea of putting a vector of BaseEffects into shapebase, because Ive been doing this for pathing.
I guess then the effect could activate shader changes on the shape which would be kinda nice.
I guess its not hugely lightweight, but seeing as its "built in" to another fairly comprehensive class, I'm not sure its that bad. If you look at things like SetCloaked (which obviously this would be a candidate for a BaseEffect derived effect).
I guess I'll give it a try, see if it causes any problems.
Still doesnt give any hints to say "client side only". Unless I build that into the effect with "IsClient" or something.
Food for thought.
Phil.
Phil.
Torque Owner Jason Sharp
Looking to do the same thing. Wish I had some suggestions but we are in the same boat. Just wanted those that are reading to know Phil is not alone. Only thing I would add is that we thought of using a LOD type level to do extra-low poly models for grass up really close, billboards for the 2nd LOD, and obviously nothing further out. Anyone?