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

[Lawson English]

Dahlia Trimble wrote:
> or if you had vnc on a prim you could put it on a texture face you are 
> working on, then full screen an image in photoshop and paint on it and 
> the changes should appear on the prim in real time
>

Sure, any VNC ssetup will allow that. Nice thing about SLPlopp is that, 
minimalist as it is, the sculpty design and UV painting code is merged 
into the same paint program so you can draw the outline of the sculpty 
and paint the texture on it using the same tools at the same time. Then 
you could puff up the drawing to make it a sculpty texture and upload it 
from localhost for 3D preview before committing it to the server. You 
could simply paint the 3D version on the prim for everyone else to see 
before upload too.

Much flexibility is possible for the design. I can see a time when 
TeaTime becomes part of SL directly, so that object state can be shared 
in myriad ways, not just as 3D drawing data, and you could have 
different combinations of world objects sharing different sets of state, 
messaging, etc., in a soup of a cloud of client-server-objects where the 
current distinctions between Client-server and P2P no longer really exist.







> -d
>
> On Fri, Jan 15, 2010 at 8:43 PM, Lawson English <lenglish5 at cox.net 
> <mailto:lenglish5 at cox.net>> wrote:
>
>     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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>     _______________________________________________
>     Policies and (un)subscribe information available here:
>     http://wiki.secondlife.com/wiki/SLDev
>     Please read the policies before posting to keep unmoderated
>     posting privileges
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges