Access to client sculptmaps?

I was idly wondering about the idea of in-world sculpty-based carpentry tools. The extreme approaches are ...

(a) the sort of external program some of you guys have made, with slow and expensive uploads, or

(b) a script that can modify a bitmap and put it into the prim with LSL. Even if that were possible (I think not yet), there would be intolerable delay each time the map was updated.

So the effective compromise would be to have a program that mofidied the bitmap inside the client, without uploading it. Then the carpenter would see the results of his work while other observers saw a placeholder. When he is satisfied with his work, he could commit it, incurring only a single upload fee and making the change visible to anyone. This would be responsive and cheap.

It could be done either by incorporating the tool program into the client, which would require huge complicity from LL, or by exposing an interface for direct manipulation of sculptmaps in the client by external programs (possibly other textures too?) . That would still need work/acceptance of contribution from LL. It would have to be done in such a way that it did not run the risk of writing to other memory (diliberately or accidentally).

If we could persuade LL to make a hook in the client for doing this, it would open some great opportunities for the sculpty tool developers as well as texture makers etc. (inclusion of the commit process would be nice but not necessary.) Anyone have a view whether it would be worth making a jira for this etc.? Pros and cons?

You used to be able to do something similar to this using the Video options to control the sculptmap image. Stopped working with v 1.20 and still does not work with 1.21. Too bad, especially since you can now point the media at images as well as video.

I need to do a bit more research here and then file a report on the JIRA. This effect seems to have broken at the same time that they fixed a related bug:

https://jira.secondlife.com/browse/VWR-5950

It might be easier for both LL and resident coders if LL were to add LSL functions that can manipulate a sculpty's mesh and a 'Update Sculpty' item in the Tools menu which would create and upload the modified sculpty's sculptmap.

Not only could it spawn lots of inworld sculpty editors, but it would give us client side animation too!.

But these inworld sculpty editors would always be a bit iffy. I've seen a few people use inworld sculpty making tools and then ponder over how to take their sculptmap outside of SL for texturing in ZBrush or something. Duh... why don't they just make the damn thing in ZBrush?.

But that still needs continuous uploading. The main point of my suggestion is to avoid that ovwehead by allowing manipulation on the users computer without the overhead of waiting for network data exchange.

Granted that slightly simplifies the separate processes of upload+insert new map, but it does nothing to provide responsive interactivity, which is the main aim of the suggestion - no file saving, no upload, no delay, immediate visualisation in the client exactly as will be seen in the final product.

Are we misunderstanding each other? I don't mean to say there's anything wrong with the things you are advocating.

The problem I see is that anything that involves uploading data from a sculpty editing program and/or downloading the data again to display in the client will never give the responsiveness needed for effective in-world editing. Even if LL come up with bitmap editing tools, we all know how long it takes to download and re-rez each time you change the map.

So the idea is to enable programs running on the local computer to directly modify the sculptmap inside the running client's memory space. That way the results of changes made in the editing program would be immediately visible to the person using the editing program, rendered by the client, in the exact visual context it is intended to occupy, with whatever surface texture was on the sculpty to begin with. No data would be uploaded or down loaded in the process, so the editing changes would be seen in real time. For other viewers and physics, the sculpty would remain in the pre-edited form (changes in dimensions are not part of the sculptmap).

Once the user was satisfied, they could then upload the data so that the changes are permanent. That would require an explicit save-upload-update process as at present, maybe improved by a combined process as you suggested. It could also be automated, but that would be a much more complicated process with more security risks, I guess.

Essentially, it is using the client, running in a genuine environment, as a real-time previewer for the editing program.

This does nothing to help with the fitting of surface textures, as you correctly point out. (Although I suppose you could have direct access to the surface texture as well.)

Well my suggestion would allow people to edit sculpties inworld in realtime (clientside only) and then upload them when they're satisfied. Your suggestion revolves around using an external program to manipulate an inworld sculpty.

Initially I thought you just wanted to be able to build alongside friends. But now it's looking like you're not really comfortable with sculpties and you're not confident that what you see in your external editor is what you're going to see inworld after uploading. If this is the case, then believe me, it does get easier!.


ps - I wasn't really mad. I'm just goofy.

But I would see it in context too!

In fact you hit the nail on the head. My main tool is a nice piece of squared paper and a biro. Then a statistics program with a bitmap editor. The only offline visualisation tool I have is an ageing brain. So really I am trying to avoid the hassle of learning openGL by using the client as a viewer. Can't blame me for trying though.

I bet you was great at battleships!