Managing objects in a PLSM scene...

I am curious about how I can manage the objects of my game using the PLSM.

I want to be able to localize updates to the clients that are connected. Needless to say, I don't want chat messages being heard all across the world, nor do I want to have each and every client constantly being sent each and every world object's updated information every time something changes in the world...

It occured to me that the PLSM may have a method for finding out the current page an object is in, and maybe even the current tile... (I hope I have the terms right... the world is made up of pages, and each page is made up of tiles, right?)

If I can get the page ID and Tile ID within that page, it should be quite easy to group objects together, and use those IDs as indexes for lookups.

I could narrow it down to something like: If you're talking normally, people in your current tile can hear you... (assuming tiles are relatively small)... if you're yelling, people in surrounding tiles can hear you... that kind of thing.

Or with objects... object changes position or orientation, and all connected clients in the same tile are notified of the change. But clients in surrounding tiles are only notified of position changes, not orientation. When moving from one tile to another, the client would THEN get the new orientation information... that's just the theory I'm working on right now, but I would like to know if what I'm saying is possible.

Mainly I guess my question is: Are there methods in the PLSM to determine the current page and tile?

Yup

Yay!

Okay, next question... is the coordinate system in a PLSM world universal?

Or is it based on page and tile?

LIke if a world is 10x10 pages, does each page have a coordinate system of XYZ where XY is from (for example) 0 to 10000 each, restarting at 0 on the next page?

Or is it from 0 to 10000 on the first page, then 10001 to 20000 the second page, etc? I presume it's the latter... where there's a universal coordinate system...

If that's the case, how do I prevent overflow if my world is really huge? I'm assuming the value is stored in a 64bit variable... probably signed, with the full range being available (0 being in the middle)... which is something like -9,000,000,000,000 to +9,000,000,000,000 ?

Ogre uses the typedef Real which can be compiled as either float or double, by default it uses float. All vectors are 3 Reals, x,y,z.

I've heard double takes more memory and slower in calculations due to float optimizations in CPU, but I'm no expert.

http://www.ogre3d.org/phpBB2/viewtopic. ... at+maximum

"Setting Ogre::Real to double makes it use the IEEE double format for all its operations. This is a 64 bit floating point format with 53 mantissa bits. This has an incredible range and should be enough for any situation. It can represent magnitude differences of 10^21 to 1. For comparison, this is almost the radius of the solar system (approx 10^12 meters) to the radius of one water molecule (approx 10^-10 meters). "

I'm not sure what range a regular float gives you. I'm working at 1 unit = 1 meter resolution and I'm pretty sure I'm okay for any size terrain that I want, within reason.

Yeah, I wasn't too concerned...

You may not be aware, but I'm using OgreDotNet for my game here, and we have our own version of Vector3 and other Math objects that we use... to improve performance, we created our own Math3D DLL that replaces the Ogre math objects... during the wrapping of Ogre, we have told the automated script to convert any references to Ogre::Vector3 to our own Math3D::Vector3...

The point is, we're using data types that you may not be familiar with. .NET types aren't too different from C++ types, except that there are some oddities on the signed/unsigned thing.

For example, "Byte" in .NET is 0 to 255... There IS an "SByte" but it's not a native type.

The floating point types in .NET are "Single" and "Double".

Single has a min/max of -3.40282347E+38 to 3.40282347E+38

Compare that to the min/max of Double:

-1.7976931348623157E+308 to 1.7976931348623157E+308

That's a huge difference.

Basically, the "float" data type in C++ would map to a "single" in .NET

To give you a better idea of how it all works, check here:
http://msdn.microsoft.com/library/defau ... stypes.asp

So I guess we're using "Single", or 32bit signed floating point for Vector3s...

So let's see...

-3.40282347E+38 to 3.40282347E+38

That means approximately a range of 680,564,694,000,000,000,000,000,000,000,000,000,000 different values.

So assuming I'm using cm as my unit of measure... there's 100 of those per meter...

So... 6,805,646,940,000,000,000,000,000,000,000,000,000 Meters

There's 1000 meters per Km...

So 680,564,694,000,000,000,000,000,000,000,000,000 Km

Okay, I think that'll work... LOL

I'm really new to Ogre, but I have some experience in software development.

If you are already using your own math-library I'd recommend to use integers or unsigned integers. Your calculations will be much faster.
Furthermore you can store exactly the same number of different values in integers and floats: 2^32 which is a bit more than 4 billion different values
If you use integers instead of floats the calculations are faster because the CPU is not forced to calculate using fractions.

You are using .Net:
int = System.Int32 (32 bits)
long = System.Int64 (64 bits)
float = System.Single (32 bits)
double = System.Double (64 bits)
^but you may also use the standard C/C++ names^

I don't really know whether you are interested in this, but I'll write it down anyway:

Most CPUs are still using a 32bit system. Floats and usual integers consist of exactly 32bits so the CPU is able to do a calculation in one cycle. Doubles and longs (integers with 64bits) consist of 64bits -> The CPU needs at least 2 cycles to do a calculation.

Please excuse my bad English. I'll improve it in my exchange year in the USA

Your English is absolutely perfect. Thanks for this info.

Yeah, the main reason we have our own math library is because we're wrapping Ogre... and any time we have to cross the wrapper to access an Ogre function, it takes a little longer to do than if we did it in native .NET code.

We basically created our own versions of Vector2, Vector3, Vector4, Quaternion, etc...