[sldev] Local textures for fast editing; was: SL 2.0?

[Lawson English]

Mike Monkowski wrote:
> Stickman wrote:
>   
>> Second Life suffers from not being able to quickly and easily see what
>> things will look like when placed inworld. Perfecting a texture
>> involves editing the texture, saving it, uploading it, applying it,
>> checking it, then going back to editing. Why can't it just be a case
>> of "tying" a local texture file to SL, and even if it's only displayed
>> locally, and then just clicking Ctrl-S to save and having it
>> immediately applied to the model you're working with?
>>     
>
> I can see where that would be quite useful, and I'm guessing it would be 
> fairly easy to implement.  I looked on JIRA and the only thing close I 
> saw was VWR-14492 "Being able to paint and texture directly onto the 
> prims rather than uploading texture from photoshop or another similar 
> program" which is much harder.  You should consider putting it out there 
> and getting some votes for it.
>
> Mike
> _______________________________________________
>   

The simplest in-world 3D tool would be taking my once and future SL <=> 
squeak plugin and applying it as a live VNC on a prim service ala 
Aimee's Recursive Life demo. 
https://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Media_Rendering_Plugin 
-I say simplest because Squeak VNC is pretty much built into the system 
by simply redirecting standard Smalltalk drawing to a pointer to an 
offscreen buffer  and because there is already a simple-to-use sculpty 
maker in Squeak: http://www.planet-plopp.com/   &  
http://www.secondplopp.com/  

 The process would involve redirecting SL PLOPP to a SL VNC session and 
mirroring the image changes to  a streaming server, with or without 
interaction/participation from the wider audience. Without the streaming 
server, it would be simply a private VNC on a prim session, which would 
look cute, but wouldn't be collaborative or all that immersive.


More elaborate tools would leverage the viewer's 3D rendering engine 
and  control widgets ala the puppeteering code.  
https://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Puppeteering_Plugin

All sorts of hybrid architectures could be developed, depending on how 
the viewer handles locally provided packets and how it exposes various 
kinds of internal events/ stages of the rendering pipeline.

An even simpler model would be to leverage a localhost server 
interfacing with a gridproxy, so that packets could be injected into the 
client via the loopback connection, while a GUI could be provided via 
the built-in browser, or html on a prim (localhost or uploaded to a 
public server or whatever).

The Seaside webserver, written in Pharo Squeak-Smalltalk, is the easiest 
way to get that kind of thing working. It works pretty much out of the 
box for this kind of thing. I've written extremely simple (barely proof 
of concept) prim manipulation tools on a localhost webpage that send 
commands via http-in to a prim. A publicly hosted Seaside server can 
provide that facility for collaboration. Any kind of webserver can do 
this, of course. Seaside is simply a nice turnkey solution that installs 
with one-click on localhost and provides an OOP interface for the GUI 
and control messages. Being required to learn /use smalltalk is the only 
drawback to this solution.

Lawson