Second Life Wiki - User contributions [en]

Comments on generality of geometries

2009-01-15T22:56:42Z

Seifert Surface:

The current setup in SL (strictly Euclidean geometry) is very restrictive. In the interests of allowing as much generality in protocols as possible, here are some possibilities for types of space to support. These are worth thinking about both for extending the variety of spaces an avatar can inhabit, but also in interfacing with clients or systems with lower power capabilities than the kinds of machines that currently run Second Life. For instance, should one be able to login an avatar that is naturally 3d to talk to avatars in a 2d world? What if someone on a low power machine (a cell phone, or a OLPC type machine) wants to login to a high powered 3d graphical world?

== Euclidean with different connectivity ==
* At most basic, as in the current SL, except that sims can be connected in other than a Euclidean grid pattern
** Already some issues here, any scripts using llGetRegionCorner to calculate distances across sims will get wrong answers. If sims are allowed to have "rotated" connections, e.g. the North side of some sim connects to the East side of another, then this gets worse.
* Next, connections as in [http://en.wikipedia.org/wiki/Portal_(video_game) Portal] (by Valve)
** Apart from the difficulty of simulating such things (which Portal does seem to do pretty well), here we have different coordinate systems interfacing within one sim. If a script asks for llGetPos, which is the right coordinate system in which to give it?
** Gravity may not always point in the direction of the negative z axis. This goes beyond scripting issues, e.g. flexi objects should know which way to droop. See also [http://en.wikipedia.org/wiki/Super_Mario_Galaxy Super Mario Galaxy].
* Next, [http://www.gametrailers.com/player/usermovies/27393.html?id=27393 The Room] (by Lionhead), particularly starting around 6:45 demonstrates portals which also alter the scale of objects that go through them.
** Many assumptions could break if things are not set up in enough generality.

== Non Euclidean ==
** [http://bork.hampshire.edu/~bernie/ Hyperbolic Maze Demo] (scroll down a bit) by Bernie Freidin, is a demo of moving around in (2 dimensional) hyperbolic space. Includes source code on the page.
*** Representations of position are (as far as I know) best done using a different system than for Euclidean geometries. Routines for translation and rotation are done differently from in Euclidean space, it's hard to see how any script that deals with geometry would be very happy with this, if it wasn't written with this in mind.
** [http://www.geometrygames.org/CurvedSpaces/index.html Curved Spaces] by Jeff Weeks (source code is there too), lets you fly through manifolds with Euclidean, hyperbolic and spherical geometries. Again, the internal representation of positions in geometries other than Euclidean works differently.

== Other dimensions ==
* 2d: There already exist many 2d virtual worlds.
** This might not be too hard, if the physics engine just tells any 3 dimensional object that its z-coordinate is always 0 for instance.
* 0d: IRC can be seen as a meeting space with no geometrical information at all.
** Presumably all that is needed is a way to turn off any (parts of) scripts/clients that use geometry.
* 4d: [http://www.urticator.net/maze/ 4D Maze Game] by John McIntosh.
** Everything will break.

These are some kinds of geometries we would like to be able to support.

This is of course a huge amount of generality. It would be unrealistic to imagine that a system could be set up such that a script/client/physics engine written for vanilla 3d Euclidean geometry would work unchanged in a hyperbolic world. However, there might be ways to mitigate things.

One suggestion: for many purposes it might be sufficient to give information in a local frame of reference around the object it is in. If all that is needed is direction data, or small scale effects, then this would be roughly sufficient, likely in any 3 dimensional geometry.

[[Category:AW Groupies]]

Sculpted Prims: Technical Explanation

2008-07-21T15:36:13Z

Seifert Surface: /* Rendering in Second Life viewer */

==Introduction==

[[Sculpted Prims|Sculpted prims]] are three dimensional meshes created from [[textures]]. Each texture is a mapping of vertex positions, where at full resolution each pixel would be one vertex, this can be less due to sampling (read below how the Second Life viewer treats your data). Each row of pixels (vertices) links back to itself, and for every block of four pixels two triangles are formed. At the top and bottom the vertices link to their respective pole.

[[Image:Sculpted-prim-explanation.png]]

==Pixel Format==

The alpha channel (if any) in position maps is currently unused, so we have 24 bits per pixel giving us 8 bits per color channel, or values from 0-255. Each color channel represents an axis in 3D space, where red, green, and blue map to X, Y, and Z respectively. If you're mapping from other software, keep in mind that not all 3D software will name their axes the same as SL does. If you have a different default orientation in SL than in your designer, compare the axes and swap where appropriate.

The color values map to an offset from the origin of the object <0,0,0>, with values less than 128 being negative offsets and values greater than 128 being positive offsets. An image that was entirely <128,128,128> pixels (flat gray) would represent a single dot in space at the origin.

On a sculpted prim that has a size of one meter, the color values from 0-255 map to offsets from -0.5 to 0.496 meters from the center. Combined with the scale vector that all prims in Second Life possess, sculpted prims have the nearly same maximum dimensions as regular procedural prims (9.961 meter diameter). The last 39mm is lost due to the fact that the maximum color value is 255, whereas 256 would be required to generate a positive offset of exactly 0.5.

==Texture Mapping==

The position map of a sculpted prim also doubles as the UV map, describing how a texture will wrap around the mesh. The image is already an explanation of what vertices correlate to what pixel, which is used to generate UV coordinates for vertices as they are created. This presents a big advantage for texture mapping over procedural prims created in Second Life because you can do all of your texturing in a 3D modeling program such as Maya, and when you export the position map you know the UV coordinates will be exactly preserved in Second Life.

==Rendering in Second Life viewer==

This analysis is based on 1.16.0(5) source and some tests.

'''Warning:''' Textures are stored using lossy JPEG2000 compression. If the texture is sized 64x64 or below the compression artifacts are numerous and very bad, once you take 128x128 they are still there but greatly diminish. Therefore for now 128x128 will give you much better results even though this is a serious memory waste. Note that going beyond 128x128 will give you little benefit so please don't!
'''Update:''' Lossless JPEG2000 compression is implemented, but does not upload all images correctly. This issue is in JIRA as [http://jira.secondlife.com/browse/VWR-2404 VWR-2404]; please vote for it to support fixing this feature.
'''Update:''' Lossless compression and retrieval appears to be all working now, as of release candidate 1.20.14 (or a few releases previously).

'''Important:''' When we refer to the texture in terms of how the viewer code sees it, the first row (0) is the bottom row of your texture. For the columns they are left to right.

The Second life viewer will at it's highest level of detail render a grid of vertices in the following form (for a sculpted prim with spherical stitching):
:1 top row of 33 vertices all mapped to a pole
:31 rows of 33 vertices taken from your texture
:1 bottom row of 33 vertices all mapped to a pole

For each row the 33rd vertex is the same as the 1st, this stitches the sculpture at the sides.
The poles are determined by taking the pixel on width/2 on the first and last row of your texture. (In a 64x64 texture that would be the 33rd pixel as we start counting columns from 0).

For example, a spherical sculpted prim at the highest level of detail Second Life supports requires a mesh of 32 x 33 vertices. If we have a 64x64 texture, this grid of vertices is sampled from the texture at the points:

(32,0) (32,0) (32,0) ... (32,0) (32,0) (32,0)
(0,2) (2,2) (4,2) ... (60,2) (62,2) (0,2)
. .
. .
. .
(0,60) (2,60) (4,60) ... (60,60) (62,60) (0,60)
(0,62) (2,62) (4,62) ... (60,62) (62,62) (0,62)
(32,63) (32,63) (32,63) ... (32,63) (32,63) (32,63)

The other types of sculpted prim stitching (torus, plane, cylinder) work similarly, but without the complication of poles. The torus requires a grid of 32x32 points (at the highest level of detail), which it samples at pixel positions 0, 2, 4, ..., 60, 62 in each direction on the texture. The plane requires a 33x33 grid, which it samples at pixel positions 0, 2, 4, ..., 60, 62, 63 in each direction. The cylinder requires a 32x33 grid, which it samples using the torus scheme in the horizontal direction and the plane scheme in the vertical.

It is recommended to use 64x64 images (32x32 textures are not officially supported for sculpted prim use and may give unexpected results). In theory 32x32 should give you (almost) the same quality but current code will not use your last (top!) row of your texture both as vertices and as the row to get the pole from (for a spherical sculpted prim). It will trigger generation of a pole 1 row early and you'll hence get your 2 last rows of vertices filled with the pole. There are however 33 vertices from the north to the south pole of a spherical sculpted prim, and so we would not expect a 32x32 texture to contain quite enough information to determine the sphere.

The next levels of detail are 17 and 9 positions (for the plane scheme sampling), or 16 and 8 (for the torus scheme sampling) which are taken in similar ways to above but with a sparser sampling. For example, instead of sampling at positions 0, 2, 4, ..., 60, 62, 63 (to get 33 points), it samples at positions 0, 4, 8, ..., 56, 60, 63 (to get 17 points). Make sure the most important pixels are positioned on those positions that are used at every LOD.

The quality of your final result is also determined by the JPEG compression. For organic shapes you may find that lossy compression is sufficient for your needs, otherwise use a 64x64 texture with lossless compression.

==Examples==

A pack of sculpture maps available for download: [http://www.jhurliman.org/download/sculpt-tests.zip sculpt-tests.zip]

An apple sculpt shown in the sculptedpreview program
[[Image:Sculpted-preview-03.png]]

An S-shaped sculpture shown in the latest version of sculptedpreview, with the sculpture map also applied as the texture map
[[Image:Sculpted-preview-04.png]]

[[Category:Sculpted Prims]]

Comments on generality of geometries

2007-12-20T20:16:34Z

Seifert Surface:

The current setup in SL (strictly Euclidean geometry) is very restrictive, and in the interests of allowing as much generality in protocols as possible, here are some possibilities:

* Euclidean with different connectivity
** At most basic, as in the current SL, except that sims can be connected in other than a Euclidean grid pattern
*** Already some issues here, any scripts using llGetRegionCorner to calculate distances across sims will get wrong answers. If sims are allowed to have "rotated" connections, e.g. the North side of some sim connects to the East side of another, then this gets worse.
** Next, connections as in [http://en.wikipedia.org/wiki/Portal_(video_game) Portal] (by Valve)
*** Apart from the difficulty of simulating such things (which Portal does seem to do pretty well), here we have different coordinate systems interfacing within one sim. If a script asks for llGetPos, which is the right coordinate system in which to give it?
*** Gravity may not always point in the direction of the negative z axis. This goes beyond scripting issues, e.g. flexi objects should know which way to droop. See also [http://en.wikipedia.org/wiki/Super_Mario_Galaxy Super Mario Galaxy].
** Next, [http://www.gametrailers.com/player/usermovies/27393.html?id=27393 The Room] (by Lionhead), particularly starting around 6:45 demonstrates portals which also alter the scale of objects that go through them.
*** Again, I'm betting this kind of thing would break if assumptions are not set up generally enough.

* Non Euclidean
** [http://bork.hampshire.edu/~bernie/ Hyperbolic Maze Demo] (scroll down a bit) by Bernie Freidin, is a demo of moving around in (2 dimensional) hyperbolic space. Includes source code on the page.
*** Representations of position are (as far as I know) best done using a different system than for Euclidean geometries. Routines for translation and rotation are done differently from in Euclidean space, it's hard to see how any script that deals with geometry would be very happy with this, if it wasn't written with this in mind.
** [http://www.geometrygames.org/CurvedSpaces/index.html Curved Spaces] by Jeff Weeks (source code is there too), lets you fly through manifolds with Euclidean, hyperbolic and spherical geometries. Again, the internal representation of positions in geometries other than Euclidean works differently.

* Other dimensions
** 2d: There already exist many 2d virtual worlds.
*** This might not be too hard, if the physics engine just tells any 3 dimensional object that its z-coordinate is always 0.
** 0d: IRC can be seen as a meeting space with no geometrical information at all.
*** Presumably all that is needed is a way to turn off any (parts of) scripts that use geometry.
** 4d: [http://www.urticator.net/maze/ 4D Maze Game] by John McIntosh.
*** Everything will break.

These are some kinds of geometries we would like to be able to support.

This is of course a huge amount of generality. It would be unrealistic to imagine that a system could be set up such that a script written for vanilla 3d Euclidean geometry would work unchanged in a hyperbolic world. However, there might be ways to mitigate things.

One suggestion: for many purposes it might be sufficient to give a script information in a local frame of reference around the object it is in. If all that is needed is direction data, or small scale effects, then this would be roughly sufficient, likely in any 3 dimensional geometry.

[[Category: AW Groupies]]

User:Dzonatas Sol/AWG Region

2007-12-20T19:42:57Z

Seifert Surface: /* Brainstorming */

{{:AWG/PageHeader}}

= Brainstorming =

* allow regions of arbitrary size and form
* allow portals and landmass-style connections between regions or a mix of both
* region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )
* User defined topology. Like bookmarks, but in 2D. Crossing a custom boundary would result in a "walking teleport"
** Extending these ideas more generally, see [[Comments on generality of geometries]].
* Multiple instances of a region within a topology. Everyone can have a front row seat for the show.
* Allow as many avatars as will fit in the virtual space of a region. Don't limit the population of a region based on architectural limitations.
* Inactive land acreage and passive prims cost only the price of disk storage. Scripts cost the price of CPU power. Avatars cost the price of bandwidth. In the LL grid, these issues are all coupled together, but this will change in a distributed world.
* Beyond the confines of the Linden grid, land, prim, script and avatar limits should not have a-priori restrictions that are relevant only to the static Linden grid. In the distributed world, local resourcing will determine which limits and costs are appropriate. One fallout from this will be that inactive land acreage will cost next to nothing, since the price of storage is in freefall.

= Implementation Thoughts =

* if we have different region domains will each of them have their own map or would it somehow work to connect certain region domains together while it would still be possible to grow one domains space? Maybe a simplified map will show connected region domains, think of a tag cloud,with the current region+domain largest in the middle, around it the connected domains with only the crossing region(s) displayed.
* Can we see into neighboring regions using a low LOD mesh dynamically created to represent the land and objects in a region?
* Virtualize the regions. If no one is in or near a region, don't waste hardware on it. If a region gets too busy, dynamically split it onto two servers, each taking half of the area.
* Allow arbitrary assignment of geography to processing resources - including dynamic migration.
** As someone who's developed 3D virtual world simulations before (and always wanted to create something like SL), the first thing that hit me when I entered SL for the first time was that sims were visible to residents (and scripts).
*** A sim is an implementation detail and residents should never need to know they exist. Making that particular initial implementation choice (to divide processing power into a regular grid and distribute it statically over separate servers) has now locked it in for the future - as removing the concept of regions would break a lot of scripted content.
*** However, it is still possible to lay a foundation that can deal with arbitrary assignment of geographic simulation to processing units (including dynamically) transparently and then add a 'backward-compatibility' layer over it which simulates the familiar square regions for legacy content (virtualizes them as suggested above).
*** Such a system could also be implemented to allow non-flat and non-contiguous geography (e.g. like planets, for example). Current continents could be mapped into small surface patches in a 'legacy' area.
*** It would also allow the possibility of distributing the various aspects of simulation of a geographic area differently - such a physics, collision, scripts, occlusion etc. (for example, if there are few physical objects over a large area, one processing unit could compute the physics for the whole area, while a larger number of processing units execute the area's scripts if required)
** See {{AWG|Virtualization}} for a scheme that addresses this.

User:Seifert Surface

2007-12-18T22:17:48Z

Seifert Surface: New page: I'm a postdoctoral lecturer in mathematics at the University of Texas at Austin. My research is in 3 dimensional geometry and topology. In SL I do a lot of mathematical sculpture, also sc...

I'm a postdoctoral lecturer in mathematics at the University of Texas at Austin. My research is in 3 dimensional geometry and topology.

In SL I do a lot of mathematical sculpture, also scripting and building, usually heavily involving 3d geometry.

My website is [http://www.segerman.org/ www.segerman.org] and Second Life specific page at [http://www.segerman.org/2ndlife.html www.segerman.org/2ndlife.html]

Comments on generality of geometries

2007-12-18T21:34:51Z

Seifert Surface: New page: The current setup in SL (strictly Euclidean geometry) is very restrictive, and in the interests of allowing as much generality in protocols as possible, here are some possibilities: * Euc...

The current setup in SL (strictly Euclidean geometry) is very restrictive, and in the interests of allowing as much generality in protocols as possible, here are some possibilities:

* Euclidean with different connectivity
** At most basic, as in the current SL, except that sims can be connected in other than a Euclidean grid pattern
*** Already some issues here, any scripts using llGetRegionCorner to calculate distances across sims will get wrong answers. If sims are allowed to have "rotated" connections, e.g. the North side of some sim connects to the East side of another, then this gets worse.
** Next, connections as in [http://en.wikipedia.org/wiki/Portal_(video_game) Portal] (by Valve)
*** Apart from the difficulty of simulating such things (which Portal does seem to do pretty well), here we have different coordinate systems interfacing within one sim. If a script asks for llGetPos, which is the right coordinate system in which to give it?
*** Gravity may not always point in the direction of the negative z axis. This goes beyond scripting issues, e.g. flexi objects should know which way to droop.
** Next, [http://www.gametrailers.com/player/usermovies/27393.html?id=27393 The Room] (by Lionhead), particularly starting around 6:45 demonstrates portals which also alter the scale of objects that go through them.
*** Again, I'm betting this kind of thing would break if assumptions are not set up generally enough.

* Non Euclidean
** [http://bork.hampshire.edu/~bernie/ Hyperbolic Maze Demo] (scroll down a bit) by Bernie Freidin, is a demo of moving around in (2 dimensional) hyperbolic space. Includes source code on the page.
*** Representations of position are (as far as I know) best done using a different system than for Euclidean geometries. Routines for translation and rotation are done differently from in Euclidean space, it's hard to see how any script that deals with geometry would be very happy with this, if it wasn't written with this in mind.
** [http://www.geometrygames.org/CurvedSpaces/index.html Curved Spaces] by Jeff Weeks (source code is there too), lets you fly through manifolds with Euclidean, hyperbolic and spherical geometries. Again, the internal representation of positions in geometries other than Euclidean works differently.

* Other dimensions
** 2d: There already exist many 2d virtual worlds.
*** This might not be too hard, if the physics engine just tells any 3 dimensional object that its z-coordinate is always 0.
** 0d: IRC can be seen as a meeting space with no geometrical information at all.
*** Presumably all that is needed is a way to turn off any (parts of) scripts that use geometry.
** 4d: [http://www.urticator.net/maze/ 4D Maze Game] by John McIntosh.
*** Everything will break.

These are some kinds of geometries we would like to be able to support.

This is of course a huge amount of generality. It would be unrealistic to imagine that a system could be set up such that a script written for vanilla 3d Euclidean geometry would work unchanged in a hyperbolic world. However, there might be ways to mitigate things.

One suggestion: for many purposes it might be sufficient to give a script information in a local frame of reference around the object it is in. If all that is needed is direction data, or small scale effects, then this would be roughly sufficient, likely in any 3 dimensional geometry.

Geometry and Physics VAG

2007-12-18T19:25:38Z

Seifert Surface: /* Architecture (Geometry View) */

: (this is an initial draft so scope and focus are still fairly open. Please add comments to the [[Talk:Geometry and Physics VAG]] if you have slightly different viewpoints so we can try to converge on a common view. This discussion could also expose other similar VAG that are needed in this area --[[User:Burhop Piccard|Burhop Piccard]] 18:38, 16 October 2007 (PDT) )

=Purpose=

The Geometry and Physics Viewpoint Advocacy Group exists to provide input for architectural design that is focused on the (virtual) physical modeling of objects.

See the [[Architecture Working Group]] and the [[Viewpoint Advocacy Groups]] for more information.

=List of concerns addressed by this viewpoint=

Areas of concern addressed by the viewpoint include:
* Describing the physical shape of the object.
* Describing the physical and material properties of the object (mass, color, material, surface texture).
* Efficient comunication of Geometric and physical properties.
* Use of open standards that allow for predictable sharing of data with various systems and tools
** Creation of data using various 3D modeling tools (i.e. Maya, Sketchup, 3D CAD, etc.)
** Reading of data by other software (other VW's, design and modeling tools, physics engines).

=Areas not addressed by this viewpoint=

* Display is not addressed by the viewpoint. This is expected to be a fairly complex topic posibly involving differnet viewers and display technologies. Another VAG is needed for this.

* Specific technologies and applications are not specifically part of this viewpoint. That is, this view is one of open archtecture capable of working with multiple applications and tools.

=Source of Viewpoint=

=Use Cases=

See the [[Architecture Working Group Glossary]] and [[usecase templates]] for more information on creating usecases. One liners are fine (and better than nothing) but more detail will result in a better understanding and a better architecture.

* Direct Creation in Second Life
** Direct Creation from Maya
** Direct Creation from Blender
** Direct Creation from Surface based modelers (please split for specific tools)
** Direct Creation from Solid Modelers (3D Mechanical CAD - please split for specific tools)
** Direct Creation from User built External Tools (i.e. such as showed up with Sculpted Prims)
** Direct Creation with User build in-world tools

* Geometry Import - File Format
** Import from Collada
** Import from OBJ
** Import from JT
** Import from 3DM

* Direct Geometry data transfer between Virtual Worlds
** Geometric asset exchange with other AWG based Asset Servers
** Geometric asset exchange with MPK20 (Sun)
** Geometric asset exchange with (who else wants to exchange data with SL? WOW? Metaverse? )

* Viewer scalability use cases
** High Fidelity graphics with High Power Computer
** Low Fidelity graphics with Low Power CPU (i.e. Cell phone)
** Viewer on low bandwidth computer
** Viewer accessing region with large amount of geometric data

* Physics Use Cases
** Mars (or other planet) virtual world/region support
** Underwater virtual world/region support
** Space (no gravity) based virtual world/region support
** non-unidirectional gravity for the whole sim, eg 'floor is the inside of a sphere'

=Related JIRA Issues=

The following JIRA issues are known problems that this VAG would like to see resolved in any future architecture. The purpose of this list it to avoid problems that exist in the curent architecture. The more typical JIRAs that are more short term in nature or can be resolved by simple code or design change should not be listed here.

* {{JIRA|SVC-73}} Request for subtractive prims and holes
* {{JIRA|VWR-858}} Ability to import 3DM files
* {{JIRA|VWR-1110}} Ability to Import .OBJ Files
* {{JIRA|VWR-1387}} Ability to import .JT files
* {{JIRA|VWR-2527}} Ability to Import .DXF Files
* {{JIRA|SVC-814}} New prim type: Geometric prim
* {{JIRA|VWR-2547}} new prim type: ropes
* {{JIRA|VWR-2260}} Polygons Clean-up Issue (a bit outdated)
* {{JIRA|SVC-885}} Physic address to prim gap/overlaps issue for vehicles.

=Organization=

== Joining ==

Anyone with an interest in this Viewpoint is welcome to join. You should join the [[AW_Groupies]] group in Second Life.

== In world meetings ==

We meet once a week in-world and more if people are available.

Also members are active on the wiki and in the SLDEV mailing list.

Meetings are scheduled via the "[http://www.google.com/calendar/embed?src=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com SL AW Groupies" google calendar]"

===Meeting Agendas===

* TBD

===Chat Logs===

* TBD

== Modeling Techniques used to express viewpoint ==

None decided.

=Architecture (Geometry View)=

See here for the [[Geometry Based Architecture View]]

Some [[Comments on generality of geometries]]

=External Links=
* Geometry
** [http://people.scs.fsu.edu/~burkardt/txt/obj_format.txt Obj format]
** [http://www.khronos.org/collada/ Collada]
** [http://www.jtopen.com/ JT Open]
** Constructive Solid Geometry (CSG) http://gts.sourceforge.net/ http://www.cgal.org/ http://opencsg.org/
** Universal 3D Standard (U3D) http://www.intel.com/technology/systems/u3d/ http://www.ecma-international.org/publications/standards/Ecma-363.htm

* Physics
** [http://www.havok.com/ Havok]
** [http://www.ageia.com/ PhysX Ageia]

=Members (Stakeholders)=

:[[User: Burhop Piccard|Burhop Piccard]] - Founder
:[[User: Morgaine Dinova|Morgaine Dinova]] - Analyst (scalability aspects)
:[[User: Wyn Galbraith|Wyn Galbraith]] - Builder & Prim Torturer
:[[User: Hypatia Callisto|Hypatia Callisto]] - 3d Artist
:[[User: JeanRicard Broek|JeanRicard Broek]] - Licenced Architect, GIS, SL Builder
:[[User: Vincent Nacon|Vincent Nacon]] - 3d Artist, Marketing Strategist, SL Builder & Scripter
:[[User: Seifert Surface|Seifert Surface]] - Mathematician, 3d Artist, Scripter

[[Category: AW Groupies]]

Geometry and Physics VAG

2007-12-18T19:15:53Z

Seifert Surface: /* Members (Stakeholders) */

: (this is an initial draft so scope and focus are still fairly open. Please add comments to the [[Talk:Geometry and Physics VAG]] if you have slightly different viewpoints so we can try to converge on a common view. This discussion could also expose other similar VAG that are needed in this area --[[User:Burhop Piccard|Burhop Piccard]] 18:38, 16 October 2007 (PDT) )

=Purpose=

The Geometry and Physics Viewpoint Advocacy Group exists to provide input for architectural design that is focused on the (virtual) physical modeling of objects.

See the [[Architecture Working Group]] and the [[Viewpoint Advocacy Groups]] for more information.

=List of concerns addressed by this viewpoint=

Areas of concern addressed by the viewpoint include:
* Describing the physical shape of the object.
* Describing the physical and material properties of the object (mass, color, material, surface texture).
* Efficient comunication of Geometric and physical properties.
* Use of open standards that allow for predictable sharing of data with various systems and tools
** Creation of data using various 3D modeling tools (i.e. Maya, Sketchup, 3D CAD, etc.)
** Reading of data by other software (other VW's, design and modeling tools, physics engines).

=Areas not addressed by this viewpoint=

* Display is not addressed by the viewpoint. This is expected to be a fairly complex topic posibly involving differnet viewers and display technologies. Another VAG is needed for this.

* Specific technologies and applications are not specifically part of this viewpoint. That is, this view is one of open archtecture capable of working with multiple applications and tools.

=Source of Viewpoint=

=Use Cases=

See the [[Architecture Working Group Glossary]] and [[usecase templates]] for more information on creating usecases. One liners are fine (and better than nothing) but more detail will result in a better understanding and a better architecture.

* Direct Creation in Second Life
** Direct Creation from Maya
** Direct Creation from Blender
** Direct Creation from Surface based modelers (please split for specific tools)
** Direct Creation from Solid Modelers (3D Mechanical CAD - please split for specific tools)
** Direct Creation from User built External Tools (i.e. such as showed up with Sculpted Prims)
** Direct Creation with User build in-world tools

* Geometry Import - File Format
** Import from Collada
** Import from OBJ
** Import from JT
** Import from 3DM

* Direct Geometry data transfer between Virtual Worlds
** Geometric asset exchange with other AWG based Asset Servers
** Geometric asset exchange with MPK20 (Sun)
** Geometric asset exchange with (who else wants to exchange data with SL? WOW? Metaverse? )

* Viewer scalability use cases
** High Fidelity graphics with High Power Computer
** Low Fidelity graphics with Low Power CPU (i.e. Cell phone)
** Viewer on low bandwidth computer
** Viewer accessing region with large amount of geometric data

* Physics Use Cases
** Mars (or other planet) virtual world/region support
** Underwater virtual world/region support
** Space (no gravity) based virtual world/region support
** non-unidirectional gravity for the whole sim, eg 'floor is the inside of a sphere'

=Related JIRA Issues=

The following JIRA issues are known problems that this VAG would like to see resolved in any future architecture. The purpose of this list it to avoid problems that exist in the curent architecture. The more typical JIRAs that are more short term in nature or can be resolved by simple code or design change should not be listed here.

* {{JIRA|SVC-73}} Request for subtractive prims and holes
* {{JIRA|VWR-858}} Ability to import 3DM files
* {{JIRA|VWR-1110}} Ability to Import .OBJ Files
* {{JIRA|VWR-1387}} Ability to import .JT files
* {{JIRA|VWR-2527}} Ability to Import .DXF Files
* {{JIRA|SVC-814}} New prim type: Geometric prim
* {{JIRA|VWR-2547}} new prim type: ropes
* {{JIRA|VWR-2260}} Polygons Clean-up Issue (a bit outdated)
* {{JIRA|SVC-885}} Physic address to prim gap/overlaps issue for vehicles.

=Organization=

== Joining ==

Anyone with an interest in this Viewpoint is welcome to join. You should join the [[AW_Groupies]] group in Second Life.

== In world meetings ==

We meet once a week in-world and more if people are available.

Also members are active on the wiki and in the SLDEV mailing list.

Meetings are scheduled via the "[http://www.google.com/calendar/embed?src=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com SL AW Groupies" google calendar]"

===Meeting Agendas===

* TBD

===Chat Logs===

* TBD

== Modeling Techniques used to express viewpoint ==

None decided.

=Architecture (Geometry View)=

See here for the [[Geometry Based Architecture View]]

=External Links=
* Geometry
** [http://people.scs.fsu.edu/~burkardt/txt/obj_format.txt Obj format]
** [http://www.khronos.org/collada/ Collada]
** [http://www.jtopen.com/ JT Open]
** Constructive Solid Geometry (CSG) http://gts.sourceforge.net/ http://www.cgal.org/ http://opencsg.org/
** Universal 3D Standard (U3D) http://www.intel.com/technology/systems/u3d/ http://www.ecma-international.org/publications/standards/Ecma-363.htm

* Physics
** [http://www.havok.com/ Havok]
** [http://www.ageia.com/ PhysX Ageia]

=Members (Stakeholders)=

:[[User: Burhop Piccard|Burhop Piccard]] - Founder
:[[User: Morgaine Dinova|Morgaine Dinova]] - Analyst (scalability aspects)
:[[User: Wyn Galbraith|Wyn Galbraith]] - Builder & Prim Torturer
:[[User: Hypatia Callisto|Hypatia Callisto]] - 3d Artist
:[[User: JeanRicard Broek|JeanRicard Broek]] - Licenced Architect, GIS, SL Builder
:[[User: Vincent Nacon|Vincent Nacon]] - 3d Artist, Marketing Strategist, SL Builder & Scripter
:[[User: Seifert Surface|Seifert Surface]] - Mathematician, 3d Artist, Scripter

[[Category: AW Groupies]]

Sculpted Prims: Technical Explanation

2007-05-28T04:49:01Z

Seifert Surface: /* Rendering in Second Life viewer */

Sculpted Prims: Technical Explanation

2007-05-28T04:48:39Z

Seifert Surface: /* Rendering in Second Life viewer */

Talk:Sculpted prim

2007-05-23T09:27:21Z

Seifert Surface: /* Reflection? */

<div style="float:right">__TOC__</div>

:[http://blog.secondlife.com/2007/04/27/the-advent-of-an-illustrious-age-of-sculpted-prims/]
:Woot ^_^ thx. -- [[User:Strife Onizuka|Strife Onizuka]] 14:45, 27 April 2007 (PDT)
:/me adds additional '''''Woot!''''' ;-P --[[User:Alison Wheels|AlisonW]] 15:42, 27 April 2007 (PDT)

Of the ways of incorporating mesh into SL this is by far the most sane. Mind posting some example textures? Frame based [[llSetTextureAnim]] would be cool too. -- [[User:Strife Onizuka|Strife Onizuka]] 12:04, 27 April 2007 (PDT)

::The textures for the shapes shown in the demo are posted in Torley's flikr stream. [http://www.flickr.com/photos/torley/474819873/in/photostream/] I haven't got Maya but I'm making a few basic architectural elements in 3ds Max, I can post them here if anyone wants to convert and play with them. [[User:Elle Pollack|Elle Pollack]] 17:10, 27 April 2007 (PDT)

I'd like to see a wireframe of the default sculptie prim (in the client > rendering > wireframe menu or ctrl shift r, one can show wireframes) Would give me a better idea of how to approximate it offline, to get a better feeling of what the possibilities/limitations of the prim are. Of course if rev 2 is around the corner, would like to see that wireframe too :D --[[User:Hypatia Callisto|Hypatia Callisto]] 11:19, 29 April 2007 (PDT)

The new preview is out! Go forth and sculpt! [[User:Elle Pollack|Elle Pollack]] 10:04, 5 May 2007 (PDT)

== [[User:Strife Onizuka|Strife's]] Observations ==

I've been examining the video posted on the blog. I took screen shots of the textures shown in the texture picker, giving the advantage of being able to see the rendered texture and compare it to real prims and their sizes.

* I'm a little fuzzy on this part. It's on or the other A)The values are centered so if you want a small dot you have to use an image that 127 or 128 grey. <s>B)The values are related to the base sphere.</s>
* The default shape is a sphere half the prim size.
* I think the bounding box is the size of the base sphere, meaning the mesh can be 3 times larger then it's bounding box.

Strife - the answer is A - point position is relative to the origin - scaled by the prim size. --[[User:Qarl Linden|Qarl Linden]] 19:49, 27 April 2007 (PDT)

:Ah good thats what I thought but was getting confused by some of the images i was looking at. If this is the case it shouldn't be too hard to build a modeling tool in C#. -- [[User:Strife Onizuka|Strife Onizuka]] 08:06, 28 April 2007 (PDT)

So the form is defined by the vectors from the origin and assumes a closed shape. What about a non-closed surface? We don't have prims which are Planes, but there's been arguably little need. Now such a primitive would allow more highly-detailed models which don't require closed forms (e.g. sheetmetal shapes for vehicles). Any plans on adding such a Prim to the library? -- [[User: Csven Concord|Csven Concord]] 09:12, 28 April 2007 (PDT)

yes, rev 2 will include "plane-like", "cylinder-like" and "torus-like" shapes, to compliment the "sphere-like" shape. (basically, all permutations of open/closed on the ends.) --[[User:Qarl Linden|Qarl Linden]] 09:39, 28 April 2007 (PDT)

:Once these are implemented, presumably it would be possible to adapt an export script to slice a large/detailed model into smaller chunks that could be pieced together in-world? --[[User:AJ DaSilva|AJ DaSilva]] 10:56, 29 April 2007 (PDT)

:I'm slightly unhappy with the handling of the edges of the map, especially at the top and bottom poles. The pulling together of the edge vertices seems forced and unnecessarily limiting. It's also difficult to texture around such a high degree vertex, and applied textures seem to to bleed a bit as well. Rather than forcing the prim to close, why not just let the edges of the sculpt texture han g free? If the builder wants a closed shape, they can align points themselves. By letting builders align the edge vertices in various ways, it should be possible to make all the "x-like" shapes mentioned above, plus a whole lot of other stuff, including multi-hole topologies and piece-wise construction of really complex shapes, all using a single kind of sculpted prim.--[[User:Watermelon Tokyo|Watermelon Tokyo]] 23:57, 22 May 2007 (PDT)

AJ - yes. one issue here is the 8 bit precision on images, and the jpeg compression applied to the data. we chose the name "sculpted" to convey this idea of "approximate" shapes - but as you can see from the plate in the plate of fruit, "approximate" is pretty close to "exact". furthermore, it wouldn't be hard to support 16bit images and higher precision jpeg compression - but let's first see whether we need it. --[[User:Qarl Linden|Qarl Linden]] 12:50, 29 April 2007 (PDT)

== LSL functionality? ==

Was wondering if there are plans to put in an LSL function to allow swapping out of the sculpt texture. This would be a nice scripted way to morph the shape through a script. This would be very useful for AV attachments (hair, tails, wings, etc.) to cut down on prim usage as the script could just morph the shape of a single prim. Or perhaps it could be applied to the AV itself (Can you say werewolf transition)? A more advanced version would make it shift between the old and new textures more smoothly rather than a sudden shift (or have an argument to specificy a 'hard' or 'smooth' morph).

I definitely like the idea of sculpted prims. However--

1) LL should embrace open source/cross-platform solutions. Embracing Maya first (as one of the most expensive platforms) seems out of place.

2) Sculpting tools like Silo and Modo should be considered. Ideally a utility program that can convert a specified .obj file (an almost ubiquitous 3D file format) to the textures for a "sculpted prim" would be ideal. This would allow content creators to use their tool of choice and then process the .obj of their sculpture into the appropriate "normal" maps for SL.

3) Guidance on linking of sculpted prims to create large sculptures than a single prim should be considered. (From reading the technical information about texture size, I get the sense we're looking at some level of subdivision of a single cube --perhaps 8x8x8 that is then deformed by the maps.)

: As I understand it, they did maya first because that's what Qarl knows how to do. He learned the think while working on the 2nd and 3rd Matrix movies. [[User:Elle Pollack|Elle Pollack]] 18:17, 27 April 2007 (PDT)

:: right you are, Elle. --[[User:Qarl Linden|Qarl Linden]] 19:51, 27 April 2007 (PDT)

What avenues have been considered for this morphing mentioned on the sculpted prims page? Some kind of interpolation between one texture and another? Or will it be akin to texture animation as we have it now? If it is interpolation between separate textures, will there finally be a llPrecacheTexture(...) added so you don't get a "blurry" object to transition to? ^.^; --[[User:Feynt Mistral|Feynt Mistral]] 21:31, 28 April 2007 (PDT)

: Feynt - our idea is to extend the media feed to inject it into the sculpted texture. there are various projects at LL to extend the media type from just quicktime to flash and html - so as these projects complete, sculpted prims will become more and more powerful. --[[User:Qarl Linden|Qarl Linden]] 12:52, 29 April 2007 (PDT)

:There are a so many problems that need to be dealt with before media streams can be used to control textures, let alone prims. Once you start importing content that intimately into the game you open up all kinds of performance, security, reliability, and privacy issues... I think we'll see Havok 4 before we'll see SL handling a dozen streamed textures in view at once, and we'll ''need'' to be able to handle a couple of dozen animated sculpted prims on the screen at once without lag if they're going to be widely used. Before depending on streams to morph prims, how about extending the mechanisms already avilable for textures in-world to the prim texture: let the script scale, rotate, shift, and animate the texture. -- [[User:Argent Stonecutter|Argent Stonecutter]] 13:43, 29 April 2007 (PDT)

:: Argent - scale/rotation/translation have little/no meaning for sculpted textures. animation, tho, is something to consider. --[[User:Qarl Linden|Qarl Linden]] 13:44, 30 April 2007 (PDT)

Are any [[LlSetPrimitiveParams]] rules or [http://wiki.secondlife.com/wiki/Category:LSL_Prim Prim] functions incompatible with sculpted prims ? --[[User:Simil Miles|Simil Miles]] 04:55, 4 May 2007 (PDT)

:well - they can't be flexi. otherwise, no - i think all the rest should work. --[[User:Qarl Linden|Qarl Linden]] 14:50, 4 May 2007 (PDT)

== PRIM_TYPE_SCULPTED ==
How about a PRIM_TYPE_SCULPTED paramater for the ll([[llGetPrimitiveParams|Get]]|[[llSetPrimitiveParams|Set]]|[[llSetLinkPrimitiveParams|SetLink]])PrimitiveParams functions? 
Syntax for Set: [PRIM_TYPE_SCULPTED, key sculp_texture]
-- [[User:Strife Onizuka|Strife Onizuka]]

: that is exactly what we've done. --[[User:Qarl Linden|Qarl Linden]] 19:51, 27 April 2007 (PDT)
: '''Warning''' : In the script editor it's PRIM_TYPE_SCULPT, not PRIM_TYPE_SCULPTED ! --[[User:Simil Miles|Simil Miles]] 09:43, 5 May 2007 (PDT)

You mentioned above different base shapes, so i take it you will be using a PrimitiveParams format like... 
[PRIM_TYPE_SCULPTED, integer style, key sculp_texture] 
or will you have a different PRIM_TYPE_* flag for each style? [[User:Strife Onizuka|Strife Onizuka]] 14:11, 28 April 2007 (PDT)

: Strife - haven't thought about it yet. i'm trying to get rev1 under control, first. :) --[[User:Qarl Linden|Qarl Linden]] 12:53, 29 April 2007 (PDT)

The full parameter list should be in there, even if rev1 ignores everything but texture, so that scripts don't break. Otherwise you'll end up needing PRIM_TYPE_SCULPTED_SPHERE, PRIM_TYPE_SCULPTED_CYLINDER, etcetera...

Should also make room for some way of switching shapes without downloading a new texture, similar to texture-switching and texture-animation.

;Suggestions:
:[PRIM_TYPE_SCULPTED, integer base_type, key sculp_texture, vector texture_scale, vector texture_offset]
::Allow for multiple shapes in a single texture map, using the scale/offset technique used by tools like XYtext.
:[PRIM_TYPE_SCULPTED, integer base_type, key sculp_texture, integer rows, integer cols, integer index, float rate]
::Allow for multiple shapes in a single texture map, using the scale/offset technique used by texture animations. If rows or cols == 0 the whole texture is used, if rate==0.0 no animation occurs.
--[[User:Argent Stonecutter|Argent Stonecutter]] 13:51, 29 April 2007 (PDT)

== Sculpt Texture ==

'''Sculpties are now live on the beta grid''' (1.16), it's time to think about [[Sharing_sculpt_maps_and_textures]].

As a graphic artist, I'd like to do thing manually on Photoshop for finer details when need to do quick minor changes. 
Can you tell what each color and greyscale value by pixels actually do to each mech points? --[[User:Vincent Nacon|Vincent Nacon]] 21:00, 27 April 2007 (PDT)

: The images are three colors (RGB) much like normal maps. Each pixel defines an X/Y/Z (coded with R, G, and B channels) offset from the origin (center of the prim). I doubt you would have much luck touching up something like this in Photoshop, you might look at something like ZBrush when we get an exporter for it. [[User:Eddy Stryker|Eddy Stryker]] 21:17, 27 April 2007 (PDT)

:: That I did understand, but I really want to go into great depth of understanding it. I like facing challenge when I can't use 3D Max, Lightwave, or even Maya. ;)
 (I don't even like Zbrush O-o, those are more for bumpmapping and texture skin.) --[[User:Vincent Nacon|Vincent Nacon]] 22:21, 27 April 2007 (PDT)

::: Vincent - the color values map to vector values in exactly the same way as "normal maps". in a nutshell: the color black (0,0,0) maps to the bottom-left-back corner (-1, -1, -1). the color white (1,1,1) maps to the top-right-front corner (1,1,1). red (1,0,0) maps to the right center point. perfect gray (0.5, 0.5, 0.5) maps to the center (0,0,0). and so on. --[[User:Qarl Linden|Qarl Linden]] 13:00, 29 April 2007 (PDT)

Since each pixel represents an offset from the center of RGB to XYZ, does that mean that the order of pixels does not make a difference? For example, swapping the colors between the first and last pixel in an image still results in the same exact object. --[[User:Dedric Mauriac|Dedric Mauriac]] 00:22, 3 May 2007 (PDT)

:The position of the pixel within the sclupt map determines which vertex of the mesh occupies that XYZ position in space. While you could randomly re-arrange the pixels within the map and end up with ''verts'' in the desired locations, the polygons connecting those verts would go all over the place. To use a humanoid mesh as an example, you might end up with a polygon connecting the left hand, right toe, and chin, another connecting the nose, left elbow and right knee, etc. As someone who's converted meshes which accidentally got then vert indexes shifted when assigning polys to them, let me tell you, it ain't pretty. ;) --[[User:Deanna Trollop|Deanna Trollop]] 04:51, 3 May 2007 (PDT)

::: Zbrush is for way more than texturing - I make all my mesh morphs with it and it's what I originally bought it for. Only when I started playing SL heavily did I start using it more for texturing :D Actually, this is really a lot like how the pixols in Zbrush work, I sometimes start with a Zsphere and just start sculpting with my tablet. Can't wait to get a Zbrush export - I'm drooling to get my hands on this feature. I'm starting right now on making zsphere stuff in the anticipation of making them into prims :D --[[User:Hypatia Callisto|Hypatia Callisto]] 07:48, 28 April 2007 (PDT)

I'ld like to make my in-world tool compatible with this type of prim, is there a sculpt texture '''UUID''' available on the main grid ? - the default one would be perfect.--[[User:Simil Miles|Simil Miles]] 23:33, 27 April 2007 (PDT)

: Torley has been putting textures online somewhere... not sure where... --[[User:Qarl Linden|Qarl Linden]] 09:41, 28 April 2007 (PDT)

:: On her flikr stream. See the link I did way at the top of this page. [[User:Elle Pollack|Elle Pollack]] 10:19, 28 April 2007 (PDT)

:: I'ld need the UUID of an in world texture...--[[User:Simil Miles|Simil Miles]] 13:24, 28 April 2007 (PDT)

::: Simil - you can take Torley's textures, uplaod them, and find their UUID, yes? am i missing something? --[[User:Qarl Linden|Qarl Linden]] 13:00, 29 April 2007 (PDT)

::: - Hm ok I can do that until it's on the main grid, but which one did you choose as the default ? the cube the apple the banana or the mushroom ? --[[User:Simil Miles|Simil Miles]] 11:58, 30 April 2007 (PDT)

::: -They won't be "system textures" at this point, and I don't know if they will be...we'll see what happens on Preview I guess? [[User:Elle Pollack|Elle Pollack]] 15:14, 28 April 2007 (PDT)

::: I'm afraid that default sculpted prims won't render or will render as sphere if they don't have a default sculpt texture.--[[User:Simil Miles|Simil Miles]] 19:10, 28 April 2007 (PDT)

Will we be able to preview rendered sculpted prims ? (Don't want to waste L$10 on every fix)--[[User:Simil Miles|Simil Miles]] 06:20, 28 April 2007 (PDT)

: yes, the texture upload preview has a "sculpted prim" mode. --[[User:Qarl Linden|Qarl Linden]] 09:41, 28 April 2007 (PDT)

I understand the basic idea, and I understand NURBS very well, but I'm having a hard time putting the pieces together... If this is NURBS-like, can you control the finer points of the shape with a knot vector? Also, can you give a brief desciption of how the texture is actually encoded? In other words, is there a defult way that the sculpt texture is mapped to the prim surface, or is that tweakable with the UV settings? --[[User:Keyser Swindlehurst|Keyser Swindlehurst]] 07:48, 28 April 2007 (PDT)

: not sure what you're asking Keyser. --[[User:Qarl Linden|Qarl Linden]] 13:00, 29 April 2007 (PDT)

:: I think I might have figured it out after I asked, but the first question was basically; does the texture contain control points for a NURBS surface (in which case, a full NURBS implementation would also need weight vectors and knot vectors), or does the texture simply contain displacement points that were generated by another tool (where the modeling could have been done with or without NURBS). I'm assuming it's the latter, yes?--[[User:Keyser Swindlehurst|Keyser Swindlehurst]] 17:50, 29 April 2007 (PDT)

::: Keyser - you are correct - it is the latter, not the former. the reason i talk about NURBS so much is that sculpties are closely related to them (both being parametric surfaces) and they share a lot of properties - and NURBS are familiar to many modelers. --[[User:Qarl Linden|Qarl Linden]] 21:34, 29 April 2007 (PDT)

:::: Are there plans for the alpha layer to figure into sculpted prims (such as weight)? --[[User:Dedric Mauriac|Dedric Mauriac]] 00:52, 3 May 2007 (PDT)

::::: See the [[ Talk:Sculpted_Prims#Flexible|Flexible]] section for discussion of what the alpha channel might be used to represent. --[[User:Deanna Trollop|Deanna Trollop]] 04:51, 3 May 2007 (PDT)

On a different topic - I think I understand the reasons why you chose this direction (you already have support for textures, etc.), but I'm wondering if it will be the best approach in the long run. For instance, I'll make the prediction that many sculpted primitives will be "heavier" than need be, both in terms of texture size and vertex count. Also, the lack of real texture coordinates, etc. is somewhat troubling in the long term. As for morphing; there are many skinning/morphing techniques that don't rely on image-based vertex positions. Finally, the JPEG questions are what started me on this line of thinking - the features that make JPEG work visually don't hold up that well for numerical data, as we've seen with normal maps and other "data textures". It might work well for a lot of prims, but JPEG isn't a great vertex compression tool. My goal is not to be negative, but I'm just curious if you see this as a long term direction or a short term stepping stone.--[[User:Keyser Swindlehurst|Keyser Swindlehurst]] 19:47, 29 April 2007 (PDT)

: Keyser - a fair question. let me address the points i disagree with first: (1) sculpted prims may be heavier than their progressive mesh counterparts - but will be significantly lighter than the existing prim usage (have you seen how many primitives are in prim hair???) (2) i don't see why you feel they don't have adequate texture coordinates (3) yes, of course there are morphing techniques for all model forms, however i wouldn't call them "trivial" like using iMovie to create a blend (4) we use jpeg2000 for our texture compression, i.e. wavelet compression, which is used successfully in all sorts of geometry compression.

: that said - yes - i share your concern. the fairest answer is that only time will tell. --[[User:Qarl Linden|Qarl Linden]] 21:45, 29 April 2007 (PDT)

::: Thanks - forgive me if I come across as argumentative. It turns out that this approach is a mix of a few subjects that I'm interested in, so I'm curious to poke a bit more. Bear with me :) Keeping with your 4 points:
1) Yes, they will be lighter than the existing approach, but one could argue that the existing approach is bad enough (for really complex meshes), that the comparison isn't even worthwhile. Again, I understand your design constraints/considerations, so perhaps I'm being unfair.
2) I come from a graphics programming background, so I'm used to having a high degree of control with texture coordinates and all other vertex data. Going forward, an approach that *only* lets you specify position is probably going to be limiting, and certainly prevents you from packing other data into the vertices (anything from normals to bone weights, etc.). Again, it probably isn't a big deal for now, but I'm trying to imagine the path that gets us from SL as it is now to a "modern" 3D app with things like postprocessing and (eventually) geometry shaders and other new features.
3) Interesting - here was my thought process: I was thinking that an interpolated morph between two meshes would be as simple as two meshes and a multiplying factor. For the iMovie blend, you have to create two meshes, encode them as textures, and generate successive frames, which would be heavier in terms of assets than the two meshes and also require more tools in the pipeline. In other words, I'm thinking about a simple Quake2 style vertex interpolation between two meshes, which would be made heavier if you used a blend movie. For something more complex, like skinning, the texture approach might be an interesting way to encode a complex animation without the problems of linear interpolation or th complexities of dealing with bones, but you would also lose the flexibility of a true skinning system.
4) To be honest, I don't know a whole lot about how well JPEG2000 works for geometry. The few papers I've skimmed seem to show that it does, but it looks like they tweak things slightly, either not treating it as just any other image, or going to the lossless mode. It will be interestng to see!
In any case, I'm looking forward to playing with this. Thanks!--[[User:Keyser Swindlehurst|Keyser Swindlehurst]] 10:53, 30 April 2007 (PDT)

Texture size can be considered a moot point, it's been stated that textures need only be 64x64, and any larger won't help. It can be hard clamped so that when you upload only textures 64x64 or smaller will be accepted, or it can be set so that sculpted prims won't accept a texture larger than 64x64 (ultimately getting a lot of "why won't my 1024x1024 texture work for sculpted prims?!11" questions). -- [[User:Feynt Mistral|Feynt Mistral]] 21:34, 29 April 2007 (PDT)

== 3D Programs for the Rich and...the not so Rich. ==
''(Discussion moved to [[Talk:Sculpted Prims: 3d Software Guide]]. [[User:Elle Pollack|Elle Pollack]] 09:04, 8 May 2007 (PDT))

== "Annoying" Questions ==

* Distance from prim center is no more than 5m? (10m from side to side.) --[[User:Vincent Nacon|Vincent Nacon]]

yes. --[[User:Qarl Linden|Qarl Linden]] 09:52, 28 April 2007 (PDT)

* No hollow and holes or even cuts? --[[User:Vincent Nacon|Vincent Nacon]]

see my comment above about the future "torus-like" topology. rev2. --[[User:Qarl Linden|Qarl Linden]] 09:52, 28 April 2007 (PDT)

* No Custom UV mapping for the (image, not model)texture itself? (unless given from plugins) --[[User:Vincent Nacon|Vincent Nacon]]

well - depends on what you mean. you can still use the texture scale/rotate/offset controls to position the textures. but no - the sculpt texture itself defines the texture space, if you know what i mean. --[[User:Qarl Linden|Qarl Linden]] 09:52, 28 April 2007 (PDT)

* Mass?
--[[User:Blakar Ogre|Blakar Ogre]] 16:49, 16 May 2007 (PDT)
similar to physics - the sculpties are approximated on the server as a flattened sphere. so whatever mass that produces is what the sculpties will have. (again - we're considering how to put sculpties into the physics engine - we've done tests and they work well - there's just the unpleasant need to have sims load textures.) --[[User:Qarl Linden|Qarl Linden]] 09:52, 28 April 2007 (PDT)

:I assume this means that any kind of animated prims would have to be phantom. --[[User:Argent Stonecutter|Argent Stonecutter]] 13:55, 29 April 2007 (PDT)

* Setting to place prim's center-point offset? (doors that rotate at one side instead of from the center) --[[User:Vincent Nacon|Vincent Nacon]]

ah - interesting. perhaps, yes. in the meantime - your exporter can be modified to produce a door which isn't centered. or sheesh - this kind of thing might be possible by photoshopping the sculpt texture... hm. --[[User:Qarl Linden|Qarl Linden]] 09:52, 28 April 2007 (PDT)

re: Photoshopping sculpt textures... this is just mental theory, but I'd think the following procedures would apply:
** To scale along a given axis, keeping the positive/negative end of that axis fixed:
***Levels, increase shadow/decrease hilight value of desired channel, respectively.
** To shift the entire model along a given axis:
***Increase or decrease brightness of the desired channel. (Note, values that get "clipped" to pure black or pure white will cause the associated verts to "squish" against the side of the bounding box.)
** To mirror-flip the model on a given axis:
***Invert the desired channel (transposing the verts on the + side to the - side, and vice versa) AND mirror-flip the image horizontally or vertically. (Skipping the second step would end up with a model mirrored ''and'' turned inside-out, because the vertex order of the polys would be reversed, similar to a 180 twist on a prim sphere)
--[[User:Deanna Trollop|Deanna Trollop]] 23:36, 28 April 2007 (PDT)

Deanna - yes, EXACTLY so. --[[User:Qarl Linden|Qarl Linden]] 13:25, 29 April 2007 (PDT)

'''Another thought, regarding photoshopping'''
:The following scheme came to mind, as a way to create a bump on a sphere in any direction. I don't think it would work exactly as I've laid it out, but soem such scheme where you use the math-like operations in adjustment layers on maps should be useful... any thoughts?
:* Create a layer containing the "unit sphere" map.
:* Duplicate it
:* Create a mask containing a fairly blurred greyscale blob.
:* Create a multiply adjustment layer using this mask.
:* Apply the multiply layer to the duplicate sphere layer.
:* Add the layers.
:--[[User:Argent Stonecutter|Argent Stonecutter]] 13:26, 2 May 2007 (PDT)

<s>* Allows flexiable? (I doubt it anyway)</s> ''this was answered in the faq, flexiprims will be implemented, just not in the first release.''[[User:Charismo Abismo|Charismo Abismo]] 08:04, 28 April 2007 (PDT) 

yes, we're thinking about how to do the flexible version. currently - flexible objects have a 1-dimensional spine that drives their motion - i'd like to make the sculpties a 2d spring system (if possible.) also - we have this unused alpha channel, which would be perfect for adding flexi information (how stiff/springing is this section of the object, etc.) --[[User:Qarl Linden|Qarl Linden]] 09:52, 28 April 2007 (PDT)
 

* I came aware that TGA takes more memories than JPG2000 format, should it support both anyway if not using Alpha Channel for flexi? --[[User:Vincent Nacon|Vincent Nacon]] 17:21, 28 April 2007 (PDT)

Vincent - internally all image types are converted to jpg2000. --[[User:Qarl Linden|Qarl Linden]] 15:18, 29 April 2007 (PDT)

* What are the polygon faces limit? Does it even resist texture going more than the limit, say a 1024 texture? (yes, going over 10,000 faces would be insane, I'd think?) --[[User:Vincent Nacon|Vincent Nacon]] 17:14, 28 April 2007 (PDT)
 

Vincent - regardless of texture size - the maximum tessellation of the sculpted grid is 32x32. larger images are simply down sampled. --[[User:Qarl Linden|Qarl Linden]] 13:25, 29 April 2007 (PDT)
 

I may be the first to complain about it, I think that's too small. 32 x 32 = 1024 vertexs Maybe 64x64(4096 vertexs)? Any higher than 128 would be too much. --[[User:Vincent Nacon|Vincent Nacon]] 14:20, 29 April 2007 (PDT)

Vincent - no. 1000 verts is roughly the render weight of our heaviest prim. if we allowed more verts, we'd need to implement some kind of prim weighting mechanism to even the load, which is all around unpleasant. if you need more detail, use more prims. --[[User:Qarl Linden|Qarl Linden]] 15:16, 29 April 2007 (PDT)

* In case of a "fool" using an real texture that wasn't made for sculpted prim, how would it react? Anyway of prevention of using non-sculpted image? I could even image an bizarre result that could lead viewer client-side crash upon rendering. --[[User:Vincent Nacon|Vincent Nacon]] 17:21, 28 April 2007 (PDT)

Vincent - yes. my word for this is "vertex vomit"... and no, it's not pretty. but there's no danger of client-side crash - just client-side nausea. --[[User:Qarl Linden|Qarl Linden]] 13:25, 29 April 2007 (PDT)

* What's the word on JPEG compression artifacts skewing the vert positions? --[[User:Deanna Trollop|Deanna Trollop]] 23:07, 28 April 2007 (PDT)

excellent question! we specifically want JPEG2000 (wavelet) compression on our vertex data for the same reason we want it on our texture data - efficiency. however you're right, this may lead to undesirable behavior as well. we're taking a wait and see position here - once people have built many sculpted prims, if there's a need, we may start tweaking our compression levels (and add support for 16bit textures, as well.) --[[User:Qarl Linden|Qarl Linden]] 13:25, 29 April 2007 (PDT)

Quarl, were any tests done on small textures? I guess there's some chance it can still compress a 64x64 texture fairly well but I doubt 32x32 (4KB total size if we have 4 channels) will see a benefit from compression. Isn't it possible to turn off compression for anything sized 32x32 or less? ----

:yes - that's one idea we'll explore if there seems a great need for it. also, 16bit channels for extra precision. but i want to wait first 'til i see how they're being used. --[[User:Qarl Linden|Qarl Linden]] 12:10, 16 May 2007 (PDT)
:: Well that's really great to know, because there does seem to be a certain [http://forums.secondlife.com/showthread.php?t=180350&page=3 demand] arising for it. [[User:Al Sonic|Al Sonic]] 00:33, 18 May 2007 (PDT)

*(Guess I need to move this down here so it gets seen) I'm wondering about UV maps too...I think it boils down to if you have UV map data in a model and you export it into the (what are we officialy calling them, sculpt maps?), is the UV mapping preserved? (Qarl had to get those textures aligned on his objects *somehow*...)[[User:Elle Pollack|Elle Pollack]] 11:50, 28 April 2007 (PDT)

Elle - sorry. :) yes, this wiki format is less than ideal for conversation... to answer your question: the sculpted prim will have the same UV space as the object in your modeling program. the UV space and the shape of the sculptie are intrinsically linked. --[[User:Qarl Linden|Qarl Linden]] 16:08, 29 April 2007 (PDT)

* Is anyone working on a 3ds Max exporter? I know it mentions it will be done just wondering if works started. [[User:Dimentox Travanti|Dimentox Travanti]] 11:57, 2 May 2007 (PDT)

: Not to my knowledge (as the only 3DS Max user I know that's been following this, who doesn't write code ;p). Your best bet in the meantime will probably to export the model and make the sculpt map in Blender. [[User:Elle Pollack|Elle Pollack]] 10:33, 4 May 2007 (PDT)

: Two methods for creating sculpties in 3ds Max are already working. For Max 8 and 9 you can use the projection modifier as detailed in [http://forums.secondlife.com/showthread.php?t=182461&page=1&pp=15 this thread]. For previous versions of Max, see [http://forums.secondlife.com/showthread.php?t=182540 this thread].--[[User:Chip Midnight|Chip Midnight]] 12:24, 9 May 2007 (PDT)

:: YES! Thank you Chip and Abu and whoever else...I was trying to figure it out by myself but I didn't have the materials experience. Will update the 3D guide soon. [[User:Elle Pollack|Elle Pollack]] 13:41, 9 May 2007 (PDT)
----

<s>: Also: what is the absolute biggest size a sculpted prim can reach ? 10 m ? 30 m ? 5 or 15 m from the origin ?</s> Anwsered: 10m from side to side, 5m from center.

Quarl, where can we discuss the viewer code? I doubt this Wiki is the ideal place for it. Still I read the code in the current source tree for beta and the stitching of top and bottom is not done correctly. --[[User:Blakar Ogre|Blakar Ogre]] 16:34, 15 May 2007 (PDT)

:we can try email - but keep in mind that i'm quickly becoming overloaded with sculptie communication - so i might not be able to reply in a reasonable manner. (sorry. :( ) --[[User:Qarl Linden|Qarl Linden]] 12:13, 16 May 2007 (PDT)

::Thanks, should be in your inbox. I kept it brief and I'm sure it's easy to fix (I gave the solution for half of it already :) ). I removed your Email-address here. Literal Email addresses in webpages are a horror. Before you know it you're in every spam-database in the world ;) --[[User:Blakar Ogre|Blakar Ogre]] 16:49, 16 May 2007 (PDT)

==Test Fodder for the Maya Plugin==
In the wild, under Creative Commons: http://www.themindstream.net/slmodels/ - 3 objects (one in 3 parts) with possibly more to come
I'm still in a technical "out of SL indfinately because of computer issues" mode, so if any of these make it as far as Preview, I want screenshots!
If there's an issue with any of the models that prevents their working, IM me through SL with details. (I still get and can respond to those). Update: I found that I had to fix some things on the pillar top and bottom; you may wish to re-get these. Some new stuff added too, and will be periodicly for a while.
[[User:Elle Pollack|Elle Pollack]] 23:58, 27 April 2007 (PDT)

ah nice. i didn't look closely - but remember you REALLY want to use single NURBS surfaces for your models - otherwise the conversion process can be painful. --[[User:Qarl Linden|Qarl Linden]] 09:56, 28 April 2007 (PDT)

Elle, I tried importing/exporting your models for you, these are the results: http://www.flickr.com/photos/8019908@N02/ THey look a bit strange to me and with no way of testing them, who knows? But the exporter seems to work ..... NOt sure about the black areas, they look scary! [[User:RamessesIII Pharaoh|RamessesIII Pharaoh]] 07:05, 30 April 2007 (PDT)

- Iiiiiinteresting...will have to see what happens when the tools go live in preview. In the meantime I've done a bunch of non-standard primitive shapes (pentagon, hexagon, octagon) that I'll upload later (those will be released to public domain, I'm not about to try and reserve rights on basic geometry) and trying to figure out what it takes to recreate those shapes as NURBS objects (joining surfaces is finiky, trying to get sharp corners is downright painfull x.x). [[User:Elle Pollack|Elle Pollack]] 12:25, 29 April 2007 (PDT)

mmmmm.... I had a look at those shapes and tried export, they look wrong but like it says, this works best with organic shapes, and i have found that polys from other programms do not seem to export correctly, especially inorganic ones. (hence the black areas). I managed a basic nurbs banana and other silly shapes, basically by deforming a sphere, as the sculpties are based on this? Anyway, all the organic shapes and some with pointy bits look ok after export. I will post some of the textures for info see flickr link above (perhaps with before and after this time). I also have to say that, having looked at the output results (and I am no expert), the concept that any human could produce these textures visually in Photoshop quite extraordinary, I remain to be proved wrong of course. [[User:RamessesIII Pharaoh|RamessesIII Pharaoh]] 07:05, 30 April 2007 (PDT)

I shall have to learn myself some NURBS than...s'what I get for being a novice game modeler. I did try to follow the guidelines for polygon objects mentioned in the FAQ. However they'll still be usefull for testing, the process of figuring out what works and what doesn't. [[User:Elle Pollack|Elle Pollack]] 10:23, 28 April 2007 (PDT)

:NURBs are quite a bit different than poly's. I'd started a tutorial to show Industrial Designers on the Core77 forum how to make single-surface models using Maya/Alias Studio. It's actually relatively rare but I prefer them bc they import into CAD cleanly. Not sure I still have it and the associated images, but if I do I'll post them. -- [[User:Csven Concord|Csven Concord]] 17:50, 28 Apr 2007 (PDT)

:That big black area you should probably photoshop gray otherwise you will have pollygons in on of the corners. What would be better would be to crop off the black areas and resize the image up (it won't effect the rendering except to give you better detail). [[User:Strife Onizuka|Strife Onizuka]] 20:18, 28 April 2007 (PDT)

== MEL Script Issues ==

''(merged two similar topics)''

has anybody got the script up and running? I am having trouble with it. pasted it but I am getting syntax errors all the way:

// Error: if (size($parents)†!= 0) //
// Error: Syntax error //

Have no idea what to do. This is definitely a revolution.

Ok, I have it, the cross has to go. I'm not sure how that works in this Wiki or any Wiki for that matter but it would be good to be able to edit the MEL. Managed to generate one of those colour depth maps (or whatever they are called) this is looking fantastic! :-)

hmmm... didn't see that plus-sign in the wiki page - perhaps your cut/paste had a problem? (line break, etc?) --[[User:Qarl Linden|Qarl Linden]] 09:57, 28 April 2007 (PDT)

indeed I can't see it either now :-) Mac and Safari I suspect.

I too had problems with Safari. I solved them by editing the llsculpt.mel page, copying the wiki page source, and pasting it into a text editor. Qarl, please provide a download link for the mel file that we can just click on. Splatting it onto a wiki page is not working for everybody.

-----------------------------

I got this error when executing the mel script:

exporting sculpt map for nurbsCylinder1 into file simple_column.bmp
// Error: Object list must contain a surface and a texture //

Um.. a texture? Surface I have, but nothin' said nothin' about having to texture map it first...

Maya 7 Unlimited full version / Mac
1.67 Ghz PowerBook G4, blah blah - [[User:GC Continental|GC Continental]] 12:25, 29 April 2007 (PDT)

Oh well... At US$7000 for Autodesk Maya I don't think I am going to be using this feature any time soon, unless of course someone is willing to pay L$2000000 for a mushroom.

:People keep refering to US$7000 version of Maya. That is the "Unlimited", most expensive version. Last I checked, the low-end but very capable version was still US$2000. Expensive but quite a bit less than the number people are throwing around. -- [[User:Csven Concord|Csven Concord]] 17:44 28 Apr 2007 (PDT)

- I don't know the specific way of doing it in Maya but try applying a basic default UVW Map: Box maps, face maps and sometimes cylinder maps are probably the best general purpose ones. Planar maps, maybe, but they can also be applied within SL. In general, you should test maps out with a basic texture like a checkerboard to check the repeats and avoid nasty stretching and deformations. [[User:Elle Pollack|Elle Pollack]] 14:48, 28 April 2007 (PDT)

Yeah I got the same error, for some reason Maya doesn't see the cylinder part of the nurbsCylinder as nurbs so the MEL script doesn't see it either. if you select the caps of the nurbsCylinder then the MEL works. Strange but true :-)

:I suspect the problem people might run into (and the capped cylinder is probably a decent example) is in thinking of NURBs primitives, patched surfaces, or "attached" surfaces as ''single'' surfaces. They may not be. If the script is looking for a single surface, then it likely needs to be a single surface; not a collection of surfaces combined into one shape (kind of like how a set of prims together comprise an "object"). If the surfaces have been created individually and "attached", then they probably need to be rebuilt as a single surface. Thus, I wouldn't expect a capped cylinder to work because it's three surfaces; not one. Another way to create that cylinder is to create an uncapped cylinder, then add some isoparms on the cap edges, and then pull the form closed (like cinching a sack). The more isoparms on the cylinder edge, the sharper the corner. Give that a try. -- [[User:Csven Concord|Csven Concord]] 18:12, 29 April 2007 (PDT)

-- What you might also like to try is drawing a CV curve of one half of the 'cylinder' and revolve to get a single surface. Worked for me, I think. I am a newbie to NURBs, (loving them though), does that make me a NURBIE? [[User:RamessesIII Pharaoh|RamessesIII Pharaoh]] 14:31, 30 April 2007 (PDT)

- I think you're right, Csven. With a single lofted surface it's just fine. It's gotta be the caps. Well, I *do* get this error: "// Error: No object matches name: loft2.boundingBoxMin //". Kinda funny, but hey, I got the bitmap! Now all I need is a client that I can test this with.... [[User:GC Continental|GC Continental]] 17:50, 29 April 2007 (PDT)

:: Caps exibit a similar behavior in 3DS Max, a fact which has been driving me batty trying to get the hang of these. x.x [[User:Elle Pollack|Elle Pollack]] 23:35, 29 April 2007 (PDT)

== Tutorials ==

I know there are probably tons of tutorials out there on how to do the basic process of what's needed for sculpted prims (3D app user wise). But if someone would want to find a really good one, or write one specificly for SL that would be most handy to pass around to people once this goes into Beta then live.

I say this now because it's best to be prepared than to be scrambling for it later on. :)

[[User:Oz Spade|Oz Spade]] 14:14, 28 April 2007 (PDT)

This might get you started [http://www.tutorialized.com/tutorial/Basic-Modeling-NURBS/4660] [[User:Eddy Stryker|Eddy Stryker]] 22:10, 28 April 2007 (PDT)

Here's some stuff that could be the start of a guide: [[Sculpted Prims Creators Guide]] [[User:Elle Pollack|Elle Pollack]] 00:34, 30 April 2007 (PDT)

Sculpted prims in Blender just started looking a whole lot easier. [http://amandalevitsky.googlepages.com/sculptedprims] [[User:Elle Pollack|Elle Pollack]] 13:16, 5 May 2007 (PDT)

An [http://www.bentha.net/sculpted2/Blender-to-sculpted.html almost complete method] to export almost anything from blender [[User:camilla Yosuke|camilla Yosuke]] 9 may 2007

Further tips on Blender ( note use of UV mirror rather than inverting X on texture ) [http://forums.secondlife.com/showthread.php?t=182033]

[http://www.joe-brown.net/SecondLife/SculptTut/SculptTut.html 3DsMax Tutorial for sculpt prim] [http://forums.secondlife.com/showthread.php?t=182540 forum thread]

== The Future: beyond the first release ==

Qarl, you already mentioned a rev 2 with more features. Are you going to keep working on this project after the initial release, or doing something else and hoping you get back to it a later time? Just asking, because projects have been abandoned before after a hopeful start. [[User:Frans Charming|Frans Charming]] 00:23, 29 April 2007 (PDT)

Frans - i hear you. i can't promise i'll remain focused on sculpties for the rest of my life - but i can promise that i'll continue improving our SL. and for the foreseeable future - there are still many things i want to accomplish with sculpties. --[[User:Qarl Linden|Qarl Linden]] 14:02, 29 April 2007 (PDT)

Another question, however implausible, would this technique be applicable to avatars? I can't imagine how many furries would love to replace the human avatar with a custom mesh (myself included). Of course the first major obstacle to that would be figuring a way to map vertices to animations currently used by SL. --[[User:Feynt Mistral|Feynt Mistral]] 01:04, 29 April 2007 (PDT)

yes. there are those at the lab who are looking at this very closely. --[[User:Qarl Linden|Qarl Linden]] 14:02, 29 April 2007 (PDT)

- I think the first step in applying these to avatars is going to be as standard attachments...face, paws, claws, tails, and yes even *those* attachments "down there". My sideline being anime/cosplay AVs, I'm allready envisioning a mask of sorts that would get the "big eyes, small mouth" of anime characters much better than AV sliders can do. The nest step would be animation, probably a series of different "keyframe" models and script calls to swap out the sculpt textures. Full-body replacement meshes to swap out for the default are not likely to be doable with this. [[User:Elle Pollack|Elle Pollack]] 12:42, 29 April 2007 (PDT)

Sculpted prims don't directly address the problem of animating objects (though using a flash animation etc as the Sculpt Texture might). If you go back and view the video again, you will see there is a one frame load time associated with these mesh. This is an issue that will need to be dealt with before changing sculpt textures is a viable method for animating objects. Continuing on this, anyone who has built an av of prims knows that clothing is a problem, it has to be custom made for the av. As to further customization of the av, LLs unlikely to do it because of bandwidth reasons. The current av mesh and skeleton are about 4 MB and have to be loaded into memory. If users had custom avs of equal or greater detail we would be seeing a much more CPU, GPU, memory and bandwidth intensive SL; better to wait a 3 -> 5 years for the hardware to catch up. -- [[User:Strife Onizuka|Strife Onizuka]] 13:05, 29 April 2007 (PDT)

For some reason the fact that the UV map changes with a change to a mesh always seems to be the last thing I think of. I didn't really think of the impact it'd have on clothing, which you're right it would definitely require custom work with every new mesh (unless SL somehow gains advanced 3d controls to allow custom texture stretching, which I don't see happening any time in the foreseeable future). I think being able to hide the human avatar would be nice though for those who do want to tackle the task of using these prims as replacement parts. Invisiprims are great and all, but they have been broken before and they do tend to be obvious if you know what to look for.

In response to the load times for the textures, you're right, which is why I had asked in another section about an llPrecacheTexture function. Argent brings up a good point I had also thought about, allowing texture animation for scripted prims (like the blink scripts for most furry heads) that swaps between a set of frames. It could mean long load times for some animated prims though if there isn't some kind of interpolation built in for 'tweening the frames, as people would probably try doing 512x512 textures to smoothly animate stuff. -- [[User:Feynt Mistral|Feynt Mistral]] 14:05, 29 April 2007 (PDT)

For a four stage animation, there wouldn't be any advantage to using more than 128x128 or 64x256 (depending on the scheme). This does assume we're talking about small animations (raised eyebrow, for example, or a slight ripple effect on a surface), or that (as Feynt suggests) "tweening" animations are available. For situations where you're "morphing" between multiple mostly-static states (opening furled wings, for example) smooth transitions would probably be unnecessary... the shapes are just too different. -- [[User:Argent Stonecutter|Argent Stonecutter]] 10:11, 30 April 2007 (PDT)

I would agree on most of it. I too wouldn't see the point for more than say, 4 to 6 frames (for different facial expressions) if there's interpolation for small movements. Certainly just the end states (a sad face, a happy face, a neutral face) would be enough and the rest would just be timing (morph from neutral to sad over 2 seconds, morph from sad to surprised in half a second, etc.). Larger changes (like, yes, unfurling wings. I was thinking more like tails and finer control for species specific behavior, such as the typical cat's tail tip moving while slightly amused, annoyed, or intrigued) would be possible if interpolation between intermediate frames were possible, and as such would require a lot more frames (something on the order of 8-10 [http://en.wikipedia.org/wiki/Keyframe key frames] for interpolation of wings opening for instance to avoid vertex mishaps and to smooth out the animation a bit). Allowing for more frames would also give more options to cycle through (like 4-8 frames for a tail wag, 2-3 more for tip swishing, another 4-6 to allow for a state that curls the tail around you in a sitting state, tails in raised states doing some of these, lowered states, etc.). If a texture could be 1024x1024, that'd allow for 256 key frames of animation, an excessive amount to be sure but it's just an example. 512x512 would allow for 64 frames, something I feel would be much more likely to be filled out by a complex shape like a wing. A tail might only have only 16 frames if interpolated between each state, while a face would only have 4-8 (assuming only expressions. Should you try creating mouth charts to approximate speech, that's easily another 12 frames.

If there is no tweening to be had however, a smooth transition would need a lot more frames, and you're a lot more likely to see 1024x1024 textures being cycled through. That's a prospect I would like to avoid, as we have enough huge textures in world as it is. That is, of course, assuming that there's going to be animation of ANY kind. -- [[User:Feynt Mistral|Feynt Mistral]] 11:49, 30 April 2007 (PDT)

A problem with keeping multiple frames in a single texture is the edges. There will be bleeding along the edges that will result in undesired effects. The only solution I see to this is to sacrifice a few pixels along the boarder to act as a bleed buffer (and have it cropped off before using). -- [[User:Strife Onizuka|Strife Onizuka]] 11:04, 30 April 2007 (PDT)

Ah yes... The white ring effect I suffered with some tail textures... -.-;

I don't think that bleeding would happen with animated meshes. Bleeding happens with animated textures because the viewer loads the whole texture into OpenGL memory and manipulates a texture transform to paint part of it onto a prim face. But for sculpted prims I think that each frame would be logically or actually extracted from the whole mesh texture and that adjacent frames would explicitly be ignored. [[User:BamBam Sachertorte|BamBam Sachertorte]] 21:00, 03 May 2007 (PDT)

I idly wonder if LL would consider a lossless format like PNGs at times like that, something that doesn't anti-alias pixels unwantedly, especially around the edges of the texture. There are plenty of tutorials out there on how to make a properly tiled texture, we don't need help from SL blurring the opposite edges of our pictures together. -- [[User:Feynt Mistral|Feynt Mistral]] 11:54, 30 April 2007 (PDT)

:Now I think about it, the edge bleeding won't be a problem because that comes from the rendering. But it's not so much the edges of the image that are the problem, but the edges of the frames. If this sort of framing is to be done, when the images are resized for LOD, the frames need to be resized individual and not the entire image all at once (or bleeding will occur). -- [[User:Strife Onizuka|Strife Onizuka]] 12:06, 30 April 2007 (PDT)

Actually I rescind my "assuming that there's going to be animation of ANY kind" remark, it's been said that there will be animation. But whether a stream (which WOULD be nice, it would solve a lot of these problems) is going to be the only method or allowing for our present texture animation model to be incorporated as well is uncertain. If so, then yes these edge bleeding issues will be a problem. If not and they'll just be streamed only at some point in the future, then that eliminates the blur issue, texture size issues for frames of animation, and probably eliminates the need for interpolation (though being the generous sort and presenting interpolation if we want it between streamed frames would be heartily welcomed!). If streams are going to be the only method though, I agree with Argent's remarks in the LSL Functionality section about it being a long time coming before SL will be able to accept dozens and dozens of streamed prims at once without dying horribly. If Mono can ever get implemented, the scripting engine can have some kind of control over the texture map for the prim. That'd remove the need for streamed content, but would still allow for dynamic prim shapes. -- [[User:Feynt Mistral|Feynt Mistral]] 12:44, 30 April 2007 (PDT)

:i don't think i agree with all this pessimism regarding streams - we're talking about an extremely low-res animation with a small amount of frame data - which will be loaded once and played in a loop. as an exercise, i have 30 such of these running in quicktime windows on my desktop (as we speak.) these things are about the data size of an animating GIF...

::Yes, now think of 30 of them running with SL active. Or better still, imagine 20 per avatar (just to be safe, because we know people will make something animated out of these for nearly every attachment point). With a dozen avatars in a sim, their load alone will be rather harsh on a client. Now throw in any objects in world that might be animated (rippling water in a pond or fountain for instance, or newer and more vibrant waterfalls. Or expertly crafted trees that sway slightly). Not to mention this streaming will be coming from outside of SL, from people with a wide range of upload speeds (my friend for instance has a 500kb download rate, but only a 20kb upload rate). Couple that with SL's need for high speed internet, and I'm not so sure streaming is an ideal situation on a grand scale. Allowing for multiple methods (especially in game scripting, because unless you're doing a playback of a rendered scene from a program like Blender, a custom program will be driving the sculpted texture stream) would ease the strain considerably. -- [[User:Feynt Mistral|Feynt Mistral]] 16:48, 5 May 2007 (PDT)

:::Feynt - you're aware that the current anim texture mechanism is vastly less efficient than a stream, right? --[[User:Qarl Linden|Qarl Linden]] 18:02, 5 May 2007 (PDT)

::::I know that memory wise it's less efficient. Who'd want to use a 1024 x 1024 texture to animate a limited number of frames when a 64x64 stream takes up much less space for a potentially infinite amount of frames? But my concern is that unless there's a mechanism to allow this streaming from a stable source, SL won't be able to support the update speed needed and prims will go wonky when there's 100+ convulsing and writhing about in a sim. If it's handled by SL, this would increase the data being sent by SL and we'll have more contributing to latency issues. If it's handled by the users who want to stream this stuff, there's issues with what happens when they turn off their computer (if they stream sculpted textures from their computer) and can their connection support a dozen streams on top of all else they want to do? The option exists to have sculpted texture streams come in from a 3rd party source, but not everyone has access to that sort of a service for free (I think I might) and for everyone else that means paying some kind of monthly fee for hosting, which limits who can use these animated sculpted prims.

::::All I know for certain about the current texture animation system is it's in place, it works for furry heads to blink eyes pretty well, and it supports a number of interesting animation styles besides simply skipping from frame to frame. As an interim solution to animation it could be allowed with the provision that, "this is not the way it's suppose to be, expect this functionality to disappear shortly." But I'm not so much for this because as mentioned elsewhere in this ever growing page, the anti-aliasing from the JPEG2000 compression would blur together edges of frames causing unwanted changes to animated models. And on top of that we'd have more large textures to download, increasing rez time (especially rez time for objects).

::::Ideally I would prefer to see dynamic textures created by script, rather than by external stream. This would potentially be even better if done client side, as it would eliminate the need for SL to stream these textures too. It'd be like writing a custom shader for a prim, except instead of generating shadow maps it creates sculpt maps. Argent [[Programmatic Textures|proposed some ideas for functions]] which make a lot of sense in this regard, but he suggests it for drawing on the face of a standard prim, rather than creating a sculpt map. It COULD be used for that purpose as well though. Alternatively (and easier for aspiring 3d programmers) the script could flat out assign the vertices to points in space through code. Assuming a local positioning system, with the center of the prim as 0, vertices could be assigned anywhere from -5 to +5 in any axis. If this functionality were added along with Mono, it would allow languages with multidimensional arrays to support assigning values to a [32][32] array of vectors. This something that you'd be able to accomplish if/when the SL client gets an editor to allow molding these prims. A client side approach does allow the prims to desync, however we already have this arrangement with particles, llTargetOmega rotations, and flexiprims and no one seems to care as long as they see roughly the same thing at roughly the same time. -- [[User:Feynt Mistral|Feynt Mistral]] 13:32, 6 May 2007 (PDT)

:::::whew - few ideas here - kinda tempted to reply inline, but that might be more confusing for those following along... basically don't much like the wiki-discussion format. :)

:::::1) current animation system vs. quicktime (etc) animation system. you worry about latency/bandwidth from SL's servers for the stream option - but then you suggest that the current animation system is fine. i don't understand - it's exactly the same transition protocol - yet your suggestion has roughly 10x the data... so... i don't get it.

:::::2) programmable shader options - YES. yes yes yes. absolutely, positively yes. sorry i haven't talked about that earlier... the astute have noticed that this geometry can easily be dynamically created on the GPU. this option is harder in that we need to provide a larger system to support it - but yes. positively a direction we want to head. --[[User:Qarl Linden|Qarl Linden]] 14:46, 6 May 2007 (PDT)

::::::#Sorry, I guess I wasn't too clear. I'm discussing streaming content versus the current texture animation system which loads a single texture. In the case of furry heads a 1024x1024 texture is divided into four 512x512 frames which are then cycled through. The image tiling rate is reduced accordingly and the image offset is changed to show the appropriate frame of the animation. For all intents and purposes, 4 frames (played forward and then backward) will account for all the important frames of a blink and looks smooth enough. Unless my client does something unexpected and caches the entire texture when it shouldn't. Because it does, I see all frames of the animation rez at the same clarity all at once as the blinking occurs. [http://www.lslwiki.net/lslwiki/wakka.php?wakka=llSetTextureAnim llSetTextureAnim] is the function I speak of. It also allows for a smooth scrolling of the texture, or spinning of the texture, which in either case would allow for some really neato effects if you think about it!
::::::#Awesomeness incarnate. >3 Will this mean a separate language like [http://en.wikipedia.org/wiki/Shader_language GLSL or HLSL] will be required? Will this be for actual shaders, or am I misinterpreting your point 2 when you mean something shader LIKE will be put together for dynamic texturing?

::::::Also, [http://www.ogre3d.org/ OGRE3D] has a lot of sample programs with it that demonstrate what it can do, chief amongst them in this case is dynamic texturing, might be worth a look. -- [[User:Feynt Mistral|Feynt Mistral]] 17:23, 6 May 2007 (PDT)

== Flexible ==

There are a few ways of doing flexible (the interface i mean).
* The simplest would be to have a smooth movement from one side of the sculpt texture to the other. But that increases the complexity of making the sculpt prim and would look strange for highly complex shapes.
* The next way that came to mind would be to add a fourth channel to the image that was the amount of flexibility that part should experience.
* The last way is conceptually the simplest and would probably be the way you would generate the map used in the previous suggestion. Provide the user access to two vectors, a position and direction vector. Anything behind the point described by the position and direction would be static.
*#You could add a plane anchored at the point that would be perpendicular to the direction, the distance above the plane would be the amount of flexibility.
*#Or you could just do the distance from the point to that part of the mesh.
**A zero direction vector would mean the entire object was to be flexible.
**A quaternion could be used instead of the direction vector (a zero magnitude quaternion could fill the same roll as a zero vector).

I think the best way would be to use the second method and release a tool that generated the distance map based on the third method (and then added it to the mesh). The advantage of having a prebaked distance map would be to remove the need for the client to do that calculation (the amount of time required to do the extra image decoding might negate this). -- [[User:Strife Onizuka|Strife Onizuka]] 08:04, 29 April 2007 (PDT)

I think the second idea of the fourth channel being a "flexichannel" would be the best idea. It would make the modeling of hair (or tendrils, or what have you) much easier. Since a 64x64 image would be mapped onto a 32x32 grid, this gives lots of room for subtle gradients in flexibility, with the base of the stalk being "coloured" as non-flexible. Reading Strife's remarks, I'm wondering if this is what he was getting at too. >) -- [[User:Feynt Mistral|Feynt Mistral]] 12:31, 29 April 2007 (PDT)
:You nailed it. 0 would be static base, 255 would be the end of the flex. By manipulating the map you could have some areas of the mesh appear less flexible then others. The problem I'm having is how you would program this, if you aren't careful you end up needing {{HoverText|IK|Inverse Kinematics}}, the flex-channel would technically allow for things like...
:*Rope with ends tied off that sways in the breeze.
:*Circus tent: points on the mesh are marked static while the rest is made flexible.
:I really don't think LL wants to be adding that to SL at this time, the amount of math isn't pretty (but it would be cool). -- [[User:Strife Onizuka|Strife Onizuka]] 12:46, 29 April 2007 (PDT)

::That WOULD be cool, but yes IK would be a tad much, not to mention computationally expensive. Working from what Qarl mentioned of the current status of flexiprims, being a 1 dimensional "string" allowing flexibility along the length of the prim, it would seem like each vertex would be an anchor point for the others around it, with a string in between it's immediate neighbours. This could allow bending in certain directions, but less (or none) in others, as some strings would remain rigid and would essentially push against the vertex should it try to bend the wrong way. This way seems a lot less computationally expensive, basically using the flexichannel as a sort of topographic map that the vertex would be moving across. It would have a natural tendency to bend towards the more flexible areas, kind of like a ball rolling down a hill. -- [[User:Feynt Mistral|Feynt Mistral]] 13:50, 29 April 2007 (PDT)

you all are very correct. flexi's currently take a lot of cpu power (all that flexi hair is a killer) so we'll be VERY careful about making flexi sculpties. which means it'll take longer... don't expect flexi in rev2. :( --[[User:Qarl Linden|Qarl Linden]] 15:30, 29 April 2007 (PDT)

As long as we get some way to control the way a prim bends based on code at the least, I don't think many people will mind it. We can implement our own "flutter in the breeze" routines if we're allowed to mold prims by code. Although I'm wary about the strain it'd put on the engine, you could also hook up a weighting system to various vertices and let the physics engine figure out how it should all work. Obviously not something for the current implementation of Havok though (one head of hair would crash a sim for sure).

Honestly I can't see a better way than what we've discussed above at the moment. Guess I need to take a couple weeks off the question to come at it from a new angle. -- [[User:Feynt Mistral|Feynt Mistral]] 16:26, 29 April 2007 (PDT)

:I just remembered something which MIGHT be of use. It's very abstract to the flexiprim idea, but there's an article on [http://www.gamasutra.com Gamasutra] about an honors thesis for [http://www.gamasutra.com/education/theses/20051028/sheppard_01.shtml realtime rendering of fur]. I've managed to hook my engines teacher on this at school, and we plan on working together on it for a tech demo by the end of my term, improving the ideas stated within. The basic rundown of the important part though is that the code within the thesis demonstrates a way to render pretty realistic thick fur which responds to a wind force. Again, it's abstract, but the system generates dots on a variety of layers stacked above the object, and these dots are generated in the right order to appear to be fur blowing in the wind. This approach could be taken for generating a line for a flexiprim to move along. Or maybe not, just a thought.

:Oh yes, you need an account with Gamasutra to see the page, but it's a good idea anyways as it has hundreds of articles which would help out. It's free too. >) -- [[User:Feynt Mistral|Feynt Mistral]] 17:32, 6 May 2007 (PDT)

== non-sculpted linkset to single sculpted prim ==

The benefit of sculpted prims is that they will allow new shapes, but also new and current shapes with less prims.

Following this idea, and excluding the fact that it would be easier to recreate from scratch, I thought that it would be interesting/handy to be able to convert a linkset of non-sculpted prims into one or more sculpted prims.

This could be made in-world, maybe without the need of the sculpt editor.

Simil - you're spoiling the surprise for rev2. :) --[[User:Qarl Linden|Qarl Linden]] 13:32, 29 April 2007 (PDT)

Or off-world, in the 3D softwares.
In this last case, linksets would need to be exported : I have completed this step by creating a tool that exports (and imports) linksets in 3 (text) formats.
The second step has aslo been completed with the Prim.Blender, SLPrims and SLmodel plugins.
The third and final step is once you have imported the linksets in the 3D softwares using the above plugins, to convert them into a model that is able to be exported as a sculpt texture.
The question then is to know if this conversion can be done and automated and if it gives a good enough result.
--[[User:Simil Miles|Simil Miles]] 12:34, 29 April 2007 (PDT)

Ooo, Qarl, does that mean a possible CSG union ability will be added? >D
It would cut down on unnecessary polygons if they were all joined into one mesh. -- [[User:Feynt Mistral|Feynt Mistral]] 13:39, 29 April 2007 (PDT)

Interesting. I wouldn't expect converted linksets to behave like a CSG though. The grid seems relatively low-resolution; a sphere and a square converted are probably going to look pretty soft and blobby. Get ready for a shift in the worlds design style. -- [[User:Csven Concord|Csven Concord]] 15:10, 29 Apr 2007 (PDT)

Csven - yes, exactly. good for organic shapes... hence the name "sculpted". :) --[[User:Qarl Linden|Qarl Linden]] 15:20, 29 April 2007 (PDT)

Hmm so sculpted prims would be appear to be much more powerful than expected, since they wouldn't only rely on sculpt texture (created in 3D softwares) but could also be created "live", by direct manipulation - terrific, this is the real news.--[[User:Simil Miles|Simil Miles]] 16:26, 29 April 2007 (PDT)

A friend in Serenity Woods made an interesting point a few days ago regarding this conversion. What happens to scripted objects which rely on a certain link number, or that rely on separate child prims? What about objects which change child prims from other prims (llSetLinkTexture for instance)? I wholly agree that this sort of thing SHOULD be made possible, having responsible sim owners converting 200-400 prim buildings into 30-50 sculpted prim buildings would be a real savings overall. However it should be up to the user which objects get this treatment because it may break some functionality otherwise. -- [[User:Feynt Mistral|Feynt Mistral]] 17:08, 6 May 2007 (PDT)

== Moving, compression ==

Ok, a few general questions:

1) How will the arrangement of pixels in the texture affect the result? If I want a cube, for example, so I have pixels for <0,0,0> <0,0,1> <0,1,0> <0,1,1> <1,0,0> <1,0,1> <1,1,0> and <1,1,1>, can I just put them in an 8x1 texture or what dimensions does it have to be? How will it affect texturing of the resulting prim?

2) How will the resulting object be scaled? Presumably the coordinates read from the texture are read based on unit values, and then scaled according to the scale of the object in the world?

3) How will JPEG2000 compression affect these textures? Will the lossiness when the textures are uploaded result in points on the prims shifting around slightly?

[[User:Yumi Murakami|Yumi Murakami]]

# Thats not quite how Sculpt Textures work. The description of the texture to make a cube would be much more complex. They aren't easy to to texture as the UV mapping will be specific to each one.
# From what I can tell in R1 a full size mesh is 1.5 times larger then the size.
# <s>You would only get lossy compression if the image type you uploaded was a JPEG. Otherwise you would get lossless compression.</s>
:-- [[User:Strife Onizuka|Strife Onizuka]] 13:12, 29 April 2007 (PDT)

Strife - not true. all of SL's textures have lossy jpeg2000 compression - regardless of their original file type. the fact that you've never noticed means it works well. :) --[[User:Qarl Linden|Qarl Linden]] 15:23, 29 April 2007 (PDT)

: *digs through the source* My bad. I'm sure thats how things were done in the past. -- [[User:Strife Onizuka|Strife Onizuka]] 16:37, 29 April 2007 (PDT)
:: In general, of course, it's bad compress twice, especialy if both methoods are lossy, cause that can make any compression artifacts worse. The only time I'd think about using JPGs for SL upload would be if I was doing a lazy grab some picture off the web type of thing but all my textures are tweaked for image quality and exported as TGA which of course is lossless. (Why compress at all instead of uploating BMP? Upload time.)

On point 3 that's what kind of confuses me. My understanding is that when you upload a texture to SL it is JPEG2000 compressed by SL itself, no matter what format you uploaded it in, and that when you upload a texture to SL it has no idea what you are going to use it for yet. So hasn't the compression already happened by the time you have the texture in your inventory, before you make your prim and set it to sculpted then drop the texture on it? Or is there some way of telling SL "this will be a sculpted prim texture, please don't compress it?" And is there some way of stopping people doing that for textures that are not to be used on sculpted prims? [[User:Yumi Murakami|Yumi Murakami]]

Yumi - let's see how this works, first, before we get too excited. but to answer your question - we could easily reduce compression on all small (64x64) textures without causing any trouble. --[[User:Qarl Linden|Qarl Linden]] 15:25, 29 April 2007 (PDT)

JPEG and JPEG2000 are different. JPEG2000 has (nearly) no artifacts being used in their standard of compression. However, when they do appear by compressing it even more, they can be seen as smoothing rather than squares or mosquito noise that you'd see in normal JPEG format. The details wouldn't lose or corrupted as much, more smoother actually. --[[User:Vincent Nacon|Vincent Nacon]] 13:57, 29 April 2007 (PDT)

== When will this be released to the main grid? ==

On the [[Sculpted Prims | article]] page for this entry, the FAQ mentions that this feature will be released into the preview grid (beta grid or first look grid(?)) sometime next week... But, when will this be released to the main grid and made available on the standard viewer? ([[User:Ina Centaur|Ina Centaur]] 16:53, 29 April 2007 (PDT))

: Considering LL's track record somewhere between 3 months and 3 years. I know it would be nice to have a calendar date, so you can decide if you will start a big project with the old prims but it isn't even in preview yet. They don't know what bugs we will find in it. The bugs we find may have huge implications or expose other bugs, it's too early to set a more precise timeline. On a side note, the last time LL announced a timeline was for Havok 2, you know how well they stuck to that. -- [[User:Strife Onizuka|Strife Onizuka]] 17:10, 29 April 2007 (PDT)

Ina - i wouldn't take Strife's negativity too seriously - the code is working well and the concepts are well explored. if the sculpties aren't on the main grid with two months, i'd be SERIOUSLY surprised. i expect much sooner than that. --[[User:Qarl Linden|Qarl Linden]] 21:26, 29 April 2007 (PDT)

We don't blame you Qarl, we blame the track records. ^.^;

We're still waiting on a Havok upgrade after many years with no word on how that's going. I had to coerce a visitor from Havok to my school in Toronto to divulge a progress report (a simple "it's going well, some problems have arisen but we're on it"). Likewise we're eagerly awaiting Mono, but there's been scarcely a whisper about that for months despite requests for updates. We want to believe though. -- [[User:Feynt Mistral|Feynt Mistral]] 21:39, 29 April 2007 (PDT)

Feynt - fair enough, fair enough. hopefully we can start fixing that record. :) --[[User:Qarl Linden|Qarl Linden]] 07:54, 30 April 2007 (PDT)

Do you think you can put forth the idea that monthly or quarterly updates on project progress across the company would be a great benefit to public relations? I know I'd feel better if I knew what was taking Mono so long. I wants my Python. >3 -- [[User:Feynt Mistral|Feynt Mistral]] 12:47, 30 April 2007 (PDT)

The recent open letter furvor has me just a bit worried...Yes the bugginess is nasty right now but it's been way too long since we've had anything new of signifigance for builders/creators (the last was 1.9.1, flexi prims and hardware lights). I can't say that resident "fix bugs first!" cries have been the cause of projects dying before, but they've likely contributed. I know Cube is a good dev (knew him pre-Linden days) and I'm getting to like you, Qarl, and I really hope you guys keep pushing this forward. [[User:Elle Pollack|Elle Pollack]] 10:47, 1 May 2007 (PDT)

:One of my big concerns with the "fix bugs first" call has been that doing so would take ''years'' and in the mean time LL would loose developers to burning out or loosing interest and going elsewhere. If LL is going to devote itself to fixing bugs then it needs to transition into that and not spring it all at once on the developer pool. -- [[User:Strife Onizuka|Strife Onizuka]] 11:36, 1 May 2007 (PDT)

::Agreed. Without innovations SL will seem to have stagnated and then you'll hear people complaining that SL is "old" because nothing new has happened in weeks/months. It's a lose/lose situation, but as my teacher says "if you try to make everyone happy, you usually end up making them all mad instead." Ongoing projects like SL, or any MMO for that matter (or MU*, as I've seen this sort of thing happen before on them as well), will have to constantly fix bugs as time wears on. There's no ifs, ands, or buts about it. Concurrent user numbers increase, requirements grow, back ends need replacing. Any change will cause bugs. With this in mind, I think the current idea of innovating and fixing bugs on the side is a better plan than just focusing on bug fixes.

::Besides, with the source gone public, if you think LL isn't fixing bugs fast enough YOU can fix them instead. -- [[User:Feynt Mistral|Feynt Mistral]] 15:15, 1 May 2007 (PDT)

== Trying to clarify how this works.. ==
Discussion moved to [[Sculpted_Prims:Clarification_Page]] as part of the [[ICFTSA]] movement by Feynt Mistral 07/05/07

== Technical explanation ==

[[Sculpted Prim Explanation]]

== More impressive visual example? ==

[http://www.sluniverse.com/pics/pic.aspx?id=164750&sort=Pictures.PictureID+desc&Name=Ina+Centaur SL Picture] shows that the apple dent can easily be done with existing torus prims. Can someone show an example of something that can't currently be done with regular prims --- such as the folds on the cloth of a Jedi hood?

:What about the 1-prim bananas? --[[User:Deanna Trollop|Deanna Trollop]] 02:37, 1 May 2007 (PDT)

:Bananas, or the reason why sculpted prims were created :D --[[User:Simil Miles|Simil Miles]] 07:27, 1 May 2007 (PDT)

:You mean like the [[:Image:Sculpted_Fruit.jpg|plate]] the fruit is sitting on? -- [[User:Strife Onizuka|Strife Onizuka]] 10:31, 1 May 2007 (PDT)

:there a picture of Patrick Star floating around the blogs - he shows a very NON-prim example of what can be done. (don't want to use that pic in any official capacity - trademarks and whatnot.) --[[User:Qarl Linden|Qarl Linden]] 11:12, 1 May 2007 (PDT)

::I wouldn't want to use that picture either, but that'd be because I don't like Spongebob. >.>;

::Don't worry though, release the new client and we'll have plenty of new pictures to put up in its place. -- [[User:Feynt Mistral|Feynt Mistral]] 15:21, 1 May 2007 (PDT)

:: Nevertheless, I'd really like to see sculpted prims being used for something like [http://www.the-reel-mccoy.com/movies/2005/images/StarWarsEpisodeIII_1.jpg the jedi hood here]. Link to Patrick Star (as manifested via sculpted prims) please? ([[User:Ina Centaur|Ina Centaur]] 16:33, 1 May 2007 (PDT))

:::Using Sculpties for a hood wouldn't be very satisfactory, you wouldn't get any movement in the fabric. -- [[User:Strife Onizuka|Strife Onizuka]] 17:44, 1 May 2007 (PDT)

:::: Ah, but you can. LSL can detect when an object changes location, and when the location is changed, script can animate the scripted prim texture to make it appear like the cloth has moved. But, anyway, seeing even a static implementation of the hood picture I linked above would be great and impressive too... gah, I've always wanted to wear a decent sith-monk hood on SL... ([[User:Ina Centaur|Ina Centaur]] 19:30, 1 May 2007 (PDT))

::::: At the moment, animation consists of constantly setting the sculpted prim's 64x64 texture to a new one. That means having all the textures in the prim, and dealing with "not fully rezzed" prim states, and it might not rez fully before your script wants to change to another "frame" of the animation. If Qarl adds our regular texture animation in, so we can have separate frames in a... say.... 256x64 texture, or if we can get streamed textures going (which he's admitted won't be happening in this revision), that'll be a better alternative. -- [[User:Feynt Mistral|Feynt Mistral]] 09:47, 2 May 2007 (PDT)

::::: Sure you can detect the objects location/rotation but it's not meaningful on an AV. There is no way to detect when the head is tilted up, down or to the sides. It makes the rotation totally useless for this. -- [[User:Strife Onizuka|Strife Onizuka]] 13:06, 2 May 2007 (PDT)

::::I think you could fake it a little if you made a hood in two parts, one to be attached to the head and one to the neck/spine, so that they move more properly with the avatar. It would look at least as good as a last-gen videogame model if you get the alignment right. When the ability to animate the texture comes along you could also script it to flutter when the avatar state is walking/flying. [[User:Elle Pollack|Elle Pollack]] 10:54, 4 May 2007 (PDT)

== Very hacky previewers ==

Discussion moved to [[Sculpted_Prims:Very_Hacky_Previewers]] as part of the [[ICFTSA]] movement by Feynt Mistral 07/05/07

== Sculpted prims using Paint Shop Pro ==

I might have found a way to create simple prims using paint shop pro. It doesn’t create complex shapes but with a little bit of understanding you can create embossed planes. It consist in creating a plane by using a horizontal gradient red texture going from black to red and back to black, [http://www.geocities.com/pamagester/Red1.jpg Red Texture] and using a vertical blue texture going from blue to black [http://www.geocities.com/pamagester/Blue1.jpg Blue Texture]. Once the plane is created in xy you can separate the channels so you have the red channel and the blue channel, you edit in the green channel and draw on it to twist the plane. This might get tricky, the left half of the green channel is the front section, the right side is the back section, so if you create a low contrast image of what you want and paste it on both sides of the channel [http://www.geocities.com/pamagester/Green1.jpg Ripled Green Example]. Once your satisfied with your picture, you combine the channels (programs like Paint shop pro and photo shop have this kind of abilities) [http://www.geocities.com/pamagester/rippleresult.jpg result]. Save it upload it enjoy ^^
[http://www.geocities.com/pamagester/RippledPrim.jpg Rippled Prim]
--[[User:Pamagester Darracq|Pamagester Darracq]] 08:28, 5 May 2007 (PDT)

: What sort of blending did you use on the layers? (are they seperate layers? Or did you work right in the red and blue channels?) [[User:Elle Pollack|Elle Pollack]] 18:04, 8 May 2007 (PDT)

== Getting crowded here! Time to branch off? ==

It's getting harder to follow half a dozen discussions on this page, so perhaps time to branch off certian things to their own pages. [[Sculpted Prims: 3d Software Guide]] for starters. [[Sculpted Prim Explanation]] can be fleshed out more and I might suggest renaming it Sculpted Prims: Technical Guide. I can start working on the software guide later. [[User:Elle Pollack|Elle Pollack]] 10:02, 5 May 2007 (PDT)

:agreed - sounds like a good plan. perhaps move the FAQ to a page named "FAQ" and the main page should route appropriately? --[[User:Qarl Linden|Qarl Linden]] 08:16, 7 May 2007 (PDT)

:: Or make the FAQ page and the main page can contain the basic explaination and links to the related articles. A mini-portal, basicly. [[User:Elle Pollack|Elle Pollack]] 11:34, 7 May 2007 (PDT)

::: To my mind, [[Sculpted Prim Explanation]] and the Glossary at [[Sculpted Prims Creators Guide]] could be merged and renamed into ''Sculpted Prims: Technical Guide'' as suggested by Elle or perhaps into something less abstract like ''Sculpted Prims: Under the Hood''? The questions and answers inside the [[Sculpted Prims Creators Guide|Glossary]] could be merged into the suggested FAQ sub-page, along with Qarl's original Questions and Answers on this page. And all pages should probably link to each other under a "See also" heading in order to avoid duplication / wasted efforts. Unless there's objections against this, I'd be happy to give that a go. '''Update:''' I've created a [[Sculpted Prims: FAQ]] page to consolidate the main FAQ with various bit and bobs around the other Sculpted Prims pages (and yes, talk pages <grins>). Please have a look — if everyone is happy with it, we could go ahead and remove the FAQ from the [[Sculpted Prims]] page and turn it into a mini-portal. Also, I have added a <nowiki>[[Category:Sculpted Prims]]</nowiki> tag to some of the existing pages so that we can merge where appropriate and avoid duplicating efforts. For example, I do think [[Sculpted_Prims_Textures|Sculpted_Prims_Textures]] and [[Sharing_sculpt_maps_and_textures|Sharing_sculpt_maps_and_textures]] should be merged. '''Late Update:''' As suggested, I have turned the front page into a "mini-portal" that routes to the existing sculptie sub-pages. It also has a news section now, Qarl.. :) I hope this will take some pressure off of the talk page.[[User:Yuu Nakamichi|Yuu Nakamichi]] 13:02, 8 May 2007 (PDT)

:::: The glossary is meant to contain not just stuff relating directly to sculpted prims but a lot of general 3d modeling lingo, like verticies, viewport, unwrap, NURBS, etc. A lot of these things are encountered on SL on a daily basis but people don't know the terms for them and they're terms people are going to start running into now, i.e, people know about the avatar templates but not the fact that they're the end result of an unwrapping process. Whereas, I see the technical guide as being specificly "how do sculpted prims work", so I don't think the two pages belong together. I do agree with most of the other things you're saying though. [[User:Elle Pollack|Elle Pollack]] 17:27, 8 May 2007 (PDT)

:::: '''Update''': The glossary page has been renamed. [[Sculpted Prims: 3d Modeling Glossary]] [[User:Elle Pollack|Elle Pollack]] 21:22, 15 May 2007 (PDT)

Another subject that probably warrants its own page is editing sculpt textures in paint programs. So here goes the link: [[Sculpt Textures in Paint Programs]] ''edit:'' It's done. I'm not sure how best to handle the relivant discussion bits though, as they're scattered through several parts of the page.''

Also, Feynt? I appreciate you're trying to help with the clutter too but the way you're going about it seems a little...arbitrary? Under-planned? The way I'm going about it is trying to figure out what topics being discussed on here ought to have a whole article dedicated to them, ''writing'' the article (or at least editing it neatly together from what others have said), ''then'' moving stuff between talk pages. [[User:Elle Pollack|Elle Pollack]] 11:48, 7 May 2007 (PDT)

:I'm actually copying entire sections out to a page titled "Sculpted Prims:<that heading name>". From there, I was thinking sub links could be made to individual discussions, or it could be left the way it was (which is, at present, kind of random in some sections). -- [[User:Feynt Mistral|Feynt Mistral]] 22:28, 7 May 2007 (PDT)

:: Part of what I'm trying to say is that discussions should be moved to other talk pages, not article pages. And you can only have an article page if you have an article to go with it. From there they can be resorted and cleaned up like I did for the 3d software threads today. But a wiki isn't like a bullitin board or forum where every discussion gets its own page.

:: Wikipedia also manages clutter by archiving old Talk Page entries, but we're barely two weeks in, it's too soon to be thinking about that. [[User:Elle Pollack|Elle Pollack]] 10:37, 8 May 2007 (PDT)

:::Fair enough. I think it'd be more productive to link these discussions to an SL forum thread though. ^.^ -- [[User:Feynt Mistral|Feynt Mistral]] 02:00, 9 May 2007 (PDT)

== thanks ==

hey everyone. i just wanted to take a moment and thank all of you for this incredible outpouring of collaboration/community development. it's been fantastic to watch.

so THANK YOU. and i hope you've had a nice weekend. --[[User:Qarl Linden|Qarl Linden]] 14:50, 6 May 2007 (PDT)

Ditto, and thank YOU for the back and forth discussion. Honestly, I think plenty of other projects could use this kind of interactivity. Now go outside and get a beer, no more coding for you today. >D -- [[User:Feynt Mistral|Feynt Mistral]] 17:03, 6 May 2007 (PDT)

== After Beta Testing Questions ==
Discussion moved to [[Sculpted_Prims_Beta_Discussion]] as part of the [[ICFTSA]] movement by Feynt Mistral on 07/05/07

== Sculpted Prims and...''Poser''?!?!? ==

This is just too sweet. [http://virtualunderworld.net/serendipity/index.php?/archives/55-Sculpted-Prims-Experiment-1.html Sculpted Avatar Face]. [[User:Elle Pollack|Elle Pollack]] 20:50, 7 May 2007 (PDT)

== HEADS UP! ==

hey all - not sure how to get this info to the community - so i'm posting here. please spread the word.

the next update to sculpties are going to have two NOT backwards compatible changes.

1) the orientation of the texture is reversed. this means all textures need to be horizontally flipped in order to work (lest they be inside out.) this change fixes the orientation discrepancy between sculptie textures and surface textures (which have required a 90 degree rotate and flip.)

2) the LSL call to set sculpties is changing to require two parameters: the texture and the topology type (as discussed above.)

--[[User:Qarl Linden|Qarl Linden]] 17:12, 10 May 2007 (PDT)

: Any updates on the LOD issues I've been hearing about? (Stuff apparently keeps reverting to spheres unless object detail settings are turned up to the max, but I don't know much else about it without being able to actualy get in the beta grid). And as for getting the word out, you might want to post in the building tips section of the SL forums too. [[User:Elle Pollack|Elle Pollack]] 09:08, 12 May 2007 (PDT)

::ah yes - sphere problem has been neutralized. ZOT. --[[User:Qarl Linden|Qarl Linden]] 12:25, 12 May 2007 (PDT)

:::Does this include when you zoom in on the object? I noticed in testing that there seems to be three ranges for the sculpted prims:
:::#The physics bounding box is slightly smaller than the visible prim (about 2-5%, which was hardly noticeable on small prims, like 0.5m, but on 10m prims it was as drastic as being up to my knees in prim)
:::#The visible prim was somewhere in the normal size range
:::#The camera's bounding box for the sculpted prim seemed larger than the visible prim, and when you zoom in too much it causes it to revert to a sphere (as if vertices are being drawn out of range, and thus defaulting to a sphere)
:::-- [[User:Feynt Mistral|Feynt Mistral]] 20:48, 14 May 2007 (PDT)

::::we had a few bugs converging to give us trouble with sculpties - 1) the code to detect degenerate sculpt textures was too sensitive, and reverted to a sphere too often 2) the sculpties were being scaled by the size, which resulted in too large sculpties (up to 20m across) which confused the LOD system, and 3) bad jpeg discard levels for low res sculpties.

::::all of which makes for confusion in figgering what is causing what. my advice is to check-out the latest build and see if you're still having the issues, and then we can proceed to a resolution... --[[User:Qarl Linden|Qarl Linden]] 12:21, 16 May 2007 (PDT)

::::: I have turned the front of this page into a sculpted prims "mini-portal", with links to all sub-pages. There's also a news section now — in case you are reading this, Qarl, please feel free to add any announcements to the front of the page; let's not bury the news here ;) [[User:Yuu Nakamichi|Yuu Nakamichi]] 15:03, 16 May 2007 (PDT)

== JPEG 2000 compression artifacts ==
Discussion moved to [[Sculpted_Prims_Beta_Discussion]] as part of the [[ICFTSA]] movement by Vincent Nacon on 05/18/07

== Reflection? ==
(Unless it was added since I last visited the beta) a checkbox to "reflect" a sculptie would be very very useful. I anticipate a lot of "pairs" of sculpt textures for symmetrical detail work... [[User:Davan Camus|Davan Camus]] 10:11 21 May 2007 (SLT)

Also good for when the thing you uploaded turns out to be inside out... happens to me about 50% of the time. [[User:Seifert Surface|Seifert Surface]]

Talk:Sculpted prim

2007-05-23T09:25:57Z

Seifert Surface: /* Reflection? */

Sculpted Prims: Technical Explanation

2007-05-22T19:00:02Z

Seifert Surface: /* Sampling */

==Introduction==

[[Sculpted Prims|Sculpted prims]] are three dimensional meshes created from [[textures]]. Each texture is a spherical mapping of vertex positions, where at full resolution each pixel would be one vertex (this is almost never the case, see Sampling). Each row of pixels (vertices) links back to itself, and for every block of four pixels two triangles are formed (total number of triangles is more because of the wrapped edges and the poles).

[[Image:Sculpted-prim-explanation.png]]

==Pixel Format==

The alpha channel (if any) in position maps is currently unused, so we have 24 bits per pixel giving us 8 bits per color channel, or values from 0-255. Each color channel represents an axis in 3D space, where red green and blue map to X, Y, and Z respectively. The color values map to an offset from the origin of the object <0,0,0>, with values less than 127 being negative offsets and values greater than 127 being positive offsets. An image that was entirely <127,127,127> pixels (flat gray) would represent a single dot in space at the origin, although it's unclear how Second Life will handle zero-volume sculpted prims like this. A sculpted prim intrinsically has a size of one meter, so the color values from 0-255 map to offsets from -0.5 to 0.5 meters. Combined with the scale vector that all prims in Second Life possess, sculpted prims have the same maximum dimensions as regular procedural prims (10 meter diameter).

==Texture Mapping==

The position map of a sculpted prim also doubles as the UV map, describing how a texture will wrap around the mesh. The image is already an explanation of what vertices correlate to what pixel, which is used to generate UV coordinates for vertices as they are created. This presents a big advantage for texture mapping over procedural prims created in Second Life because you can do all of your texturing in a 3D modeling program such as Maya, and when you export the position map you know the UV coordinates will be exactly preserved in Second Life.

==Sampling==

64x64 textures are common for position maps, but in practice the highest level of detail for sculpted prims in Second Life is a grid of 32x32 vertices, and the lower level of detail uses 16x16 vertices. Second Life samples individual pixels but fewer of them total.

For example, a sphere at the highest level of detail requires a mesh of 32 x 33 vertices, the top row of which is then averaged together to glom all of those vertices into a single one to form the North pole. The same thing happens to the bottom row. If we have a 64x64 texture, this grid of vertices is sampled from the texture at the points:

(0,0) (2,0) (4,0) ... (60,0) (62,0)
(0,2) (2,2) (4,2) ... (60,2) (62,2)
. .
. .
. .
(0,60) (2,60) (4,60) ... (60,60) (62,60)
(0,62) (2,62) (4,62) ... (60,62) (62,62)
(0,63) (2,63) (4,63) ... (60,63) (62,63)

Notice the last row, needed to get the 33rd row of vertices.

In general, if we have a 2^n by 2^n texture, and we are making a grid of 2^m by (2^m)+1 vertices, then the (i,j)th vertex position (0 <= i < 2^m, 0 <= j <= 2^m) is determined by the pixel at:

(2^(n-m)*i, 2^(n-m)*j) if j != 2^m
(2^(n-m)*i, (2^n) - 1) if j == 2^m

It is recommended to use 64x64 images.

==Examples==

A pack of sculpture maps available for download: [http://www.jhurliman.org/download/sculpt-tests.zip sculpt-tests.zip]

An apple sculpt shown in the sculptedpreview program
[[Image:Sculpted-preview-03.png]]

An S-shaped sculpture shown in the latest version of sculptedpreview, with the sculpture map also applied as the texture map
[[Image:Sculpted-preview-04.png]]

[[Category:Sculpted Prims]]

Sculpted Prims: Technical Explanation

2007-05-22T18:58:55Z

Seifert Surface: /* Sampling */