Getting heightmap of sim including prims?

Hi,

I'm trying to get a heightmap of my island including all buildings/prims.

I know it is easy to get the terrain height, but don't know how to also get the height of the prims on the terrain. Any suggestions would be highly appreciated.

Is there a way to get the distance to the nearest prim in any direction? Then I could have an object fly over the sim and determine the distance to the buildings on the ground. Or is there another way?

Thanks a lot,
C

To find the nearest prim you can use llSensor, and then use something like llVecDist (llGetPos (), llDetectedPos (n)) in the resulting sensor event.

I can only think of a brute force approah to the height map: rez a prim at a height over various locations in the region and have it lower itself until it collides with something. There's probably cleverer ways of doing that, though.

Thanks a lot Pete, I think that llSensor & llVecdist (in a moving object) should do the trick if the scan area is limited to a very small angle, effectively behaving like a beam that scans downwards. This should result in a heightmap of the sim. I'll try it out.

What would be the best way to store the data that this scan collects? I know I can't write to notecards.

depends on what you'll be doing with the data, and maybe even what your xy resolution will be.

you can discard the x/y coordinates if you know the mapping pattern (switchback, spiral, etc) and just replay the data in reverse...

your resulution is how bing an area you are scaning for your data point... 4m^2 is only 49 data points, you could possible send it to chat, maybe in chunks. you could email it in chunks if it's bigger, or if you're building a miniature you could send the data to the model and build is as you work, using region say.

Thanks Void, good ideas.

I wrote a scanning script using llSensor with a really thin beam, but the sensor (llDetectedPos) returns only the center of the detected object, and only detects ( = calls a sensor event) it if its position is *exactly above* the object center. (Example: scanning a 10x10x10 sphere every 1m in x and y direction only returns a single detection point, at the center, and nothing everywhere else).

So now I'm going to use llGetPrimitiveParams on the detected prim to get its size and shape. Is this a good idea? And what about linked objects?

Maybe dropping an object from the sky and checking where it collides would be an easier solution after all? Which functions would you use for this? If I detect a collision and then use a detection (llDetected*) function on the prim, wouldn't that give me exactly the same information as now with the sensor? Is the collision detected everywhere on the object, or only at its center (like the sensor beam)?

Unfortunately, llGetPrimitiveParams works only for the prim in which the script is in. And on collision you only need the position of the survey prim, and you could take into account its known size.

having some thoughts about using llVolumeDetect but I'm not sure if objects that pass through the volumes center will be detected, or only if the object center passing through the volume will trigger. wouldn't need physics for it... just move it up and down in place... it bears looking in to

Thanks for the comments, Pete and Void!

I looked into llVolumeDetect, but it "only detects physical objects and avatars" according to the slwiki, meaning it would not detect non-physical buildings (and most buildings are not physical?). Additionally, "when moving via llSetPos() by a loop of stages, collision events will not trigger". So it seems to be geared towards physical objects?

Otoh, the lslwiki says "llVolumeDetect should not be used on physical objects! Doing so will cause the object to fall through the ground and go off-world". Which makes moving a "detector" object rather hard, given that it can't be moved using llSetPos, but the alternative llMoveToTarget is for physical objects?

Maybe I am misunderstanding something, I'm rather new to LSL scripting.

you can set a hoverheight I believe to keep it from falling offworld... but then i'd be worried about drift, or random interference form other people if it's physical...

phantom + sensor might be a way to go...

detecting and rebuilding each prims position, rotation and height seems so... brute force though... and repetitive...

maybe a large physical "bullet" fired straight down, that dies on first contact after reporting the prim it hit... that would seem to at least cut down on which items were being detected for the heightmap.

much trickier idea than it looks like up front.

Through HTTPRequest into a SQL database. I'm pondering about doing this for my next scanner major version, there are pros and cons. But for private use, you shouldn't hesitate it's the best way to go.

I use collision to determine the object height now. Having one object fly over the sim and shoot bullets down until they collide.

The only drawback I can see here is that the bullet speed influences the collision point. My guess is that the bullet collides and the "collision" event returns its position, but if the bullet is fast, it has already moved a bit further by the time llGetPos() is called, thus skewing the results. But this skew seems constant and can therefore be taken into account.

Another thing is collision surfaces. A box gives me a collision as expected, where I see the surface. But a sphere returns a very low resolution "sphere" bounding box with only two different heights (for a 10m sphere), so basically a box with a smaller box on top. Does anyone know whether there is a menu option in any viewer (e.g. Emerald) to see those surfaces?

Other comments on this are of course appreciated.

Twisted: thanks I will look into that, although it seems a bit overkill to me as I'll only use the scanner on my own sim once in a while, so maybe I'll just send the results by email.

Any viewer will do, turn object detail to the lowest possible. The lowest LOD shape is used for the physics mesh. There tends to be some difference though here and there, for example the cut faces for prims seems to be triangulated in the reverse order for the physics engine. Also, sculpties use a 'true' sphere collision shape compared to the sphere prim which uses a mesh.


Regarding collisions stuff and heightmapping. I would personally suggest using my custom clients' Script API together with the Raycasting functions, but my API is still evolving and too confusing for intermediate scripters in the current stages.

I'd suggest as others said and shoot a slow bullet, you might want to be reminded that you don't exactly need to have it do one bullet at once, for example, starting from each collumn in a grid with 64 bullets at once and moving row by row.

Thanks for the info and suggestions Nexii. Are you doing raycasting using LSL (with a bullet?), or is it integrated in your client?