In article <483627a0$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > So.. The question becomes, knowing what I need, how the bloody heck 
> > do you implement it?
> 
> I would say you can separate the security from the calculations pretty 
> easily.
> 
> 1) The client knows what it's drawing at each pixel, so when you click,
 
> compute which bit of mesh was shown in the pixel the mouse was in when 
> the click occurred. Report that to the server.
> 
> 2) All the *server* has to do is verify that the client is capable of 
> seeing the bit of mesh that you clicked on. In other words, the server 
> doesn't have to figure out where you clicked - it only has to confirm 
> that you could have clicked on what the client figured out. Given the 
> server knows the object's mesh coords and the camera's location, this 
> should be pretty easy. A piece of mesh partially obscured might make 
> this a little harder.
> 
Well. Yeah, I figure this is the case, but I also figured that complex 
objects "might" be a bit more complicated than testing a bounding box 
around them. However, if they already do basic detection to determine if 
the need to "test" for such things anyway, then the bounding box already 
exists. Since I don't know near enough of the math, I have no clue how 
complicated something like a sculptie would make the whole mess, never 
mind linked objects.

> > Basically, I am going to try to propose an extension to the "touch" 
> > functions in a virtual environment, which works similar to the image 
> > maps used in HTML pages (so you can make images/buttons on the texture
 
> > as target points), 
> 
> Yeah. My object in SL took 57 objects to make a 5x5 board for 2 people.
 
> Messy to instantiate. :-)
> 
Ah. You guessed it. lol Seriously though, HUDs and even things like 
kiosks and door keypads waste anything from 6-7 prims and textures for 
something "simple", like the animation overriders, to 9 for a keypad, to 
10+ for some kiosks, etc. And every damn one has to have a script to 
"say" things to the key prim, which needs a listener, etc. Just making 
it detect where on a texture you touched, so you don't need all the damn 
prims, could cut the amount of crap running server side, as well as the 
number of prims and textures to be sent/rendered, in half.

As for your game.. Not sure that would have helped much. You still need 
a key "listener" with the board texture, to detect where you clicked, 
instead of talking to it, then lots of listeners in the pieces, to make 
them rez, move and derez when needed. Its possible it would have helped 
some, but maybe not as much as you think in that case.

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message