• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-4418
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: TigroSpottystripes Katsu
Votes: 13
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

sculpted visuals, and parametric collision mesh in a single prim

Created: 28/Jan/08 05:27 PM   Updated: 16/Aug/09 08:45 AM
Return to search
Component/s: Building (in-world), Graphics
Affects Version/s: None
Fix Version/s: None

Issue Links:
Relates


 Description  « Hide
the idea basicly would be to instead of having sculpty being a separated type of prim, enable any of the old types of prims to look like a sculpty while still having the parametric collision mesh of regular prims

for example, one would make a pretty sculpty chair model, and have the system think it is a path cut box ( so avatars and phys objects would not only collide with the legs of the chair as expected, but would also colide with the top of the seat and the back of the chair aswell), stairs could look like having several steps, while stilll being seen as a ramp by the phys engine using a single prim, one could make an intricate looking cave entrance, and have the system deal with it as if it was a stretched torus, you got the point

the sculpted look would be an option, perhaps something like the flexy option, perhaps in a separated tab, and would have it's own parameters regarding position, rotation and scale, to allow the custom shapes to be more easily aligned with the collision mesh

to not break existing content, old sculpties would be converted to prims of the proper type (the default sculpties would be spheres, the ones with torus topology would be torus, the plane would be flattened boxes etc), so for example, the default apple would be a sphere with the appearance of an apple. as for scripts, I'm a bit unsure if there would be a clean way of having backward compatibility, but it shouldn't be too hard to make it not break most of the current scripts

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
TigroSpottystripes Katsu made changes - 28/Jan/08 05:30 PM
Field Original Value New Value
Summary sculted visuals, and parametric collision mesh in a single prim sculpted visuals, and parametric collision mesh in a single prim
[ Permlink | « Hide ]
IAm Zabelin added a comment - 14/Mar/08 07:24 PM
This is a very good idea.

Please give this serious consideration.

Specially as it seems that correct sculptie collision meshes won't be happening soon. This would re-use much of the existing code and methodologies and could be implemented pretty quick. It will offer an intermediate and very necessary solution to sculpt collisions.

So the idea is to separate the sculpt definition (on a new tab etc as Tigro says) including a separate rotation and position (to allow relative offsetting it from the collision map), and other than that users define the collision-map as best they can using the existing prim torturing tools.

Excellent !


IAm Zabelin made changes - 14/Mar/08 08:57 PM
Link This issue is related to by SVC-956 [ SVC-956 ]
TigroSpottystripes Katsu made changes - 26/Mar/08 07:33 PM
Description the idea bascily would be to isntead of having sculpty being a separated type of prim, enable any of the old types of prims to look like a sculpty while still having the parametric collision mesh of regular prims


for example, one would make a pretty sculpty chair model, and have the system think it is a path cut box ( so avatars and phys obejcts would not only colide with the legs of the chair as expected, but would also colide with the top of the seat of the chair aswell), stairs could look like having several steps, while stilll being seen as a ramp by the phys engine usign a signle prim, one could make an intricate looking cave entrance, and have the system deal with it as if it was a streteched torus, you got the point


the sculpted look would be an option, perhaps somthing like the flexy option, perhaps in a separated tab, and would have it's own parameters regarding position, rotation and scale, to allow the custom shapes to be more easilly aligned with the collision mesh

to not break existing content, old sculpties woudl be converted to prims of the propper type (the default sculpties woudl be spheres, the ones with torus topology would be torus, the plane woudl be flatteneed boxers etc), so for example, the default apple would be a sphere with the appearance of an apple 		the idea basicly would be to instead of having sculpty being a separated type of prim, enable any of the old types of prims to look like a sculpty while still having the parametric collision mesh of regular prims


for example, one would make a pretty sculpty chair model, and have the system think it is a path cut box ( so avatars and phys objects would not only colide with the legs of the chair as expected, but would also colide with the top of the seat and the back of the chair aswell), stairs could look like having several steps, while stilll being seen as a ramp by the phys engine using a single prim, one could make an intricate looking cave entrance, and have the system deal with it as if it was a stretched torus, you got the point


the sculpted look would be an option, perhaps somthing like the flexy option, perhaps in a separated tab, and would have it's own parameters regarding position, rotation and scale, to allow the custom shapes to be more easily aligned with the collision mesh

to not break existing content, old sculpties would be converted to prims of the proper type (the default sculpties would be spheres, the ones with torus topology would be torus, the plane would be flattened boxes etc), so for example, the default apple would be a sphere with the appearance of an apple. as for scripts, I'm a bit unsure if there would be a clean way of having backward compatibility, but it shouldn't be too hard to make it not break most of the current scripts
[ Permlink | « Hide ]
JimmyJ Sands added a comment - 19/Jul/08 02:36 PM
This is the best idea I have seen after the lossless upload idea.

Sue Linden made changes - 13/Nov/08 11:02 AM
Workflow jira-2007-12-22a [ 51534 ] jira-2008-11-14 [ 62736 ]
Sue Linden made changes - 13/Nov/08 11:20 AM
Workflow jira-2007-12-22a [ 62736 ] jira-2008-11-14 [ 68726 ]
Sue Linden made changes - 13/Nov/08 04:35 PM
Workflow jira-2008-11-14 [ 68726 ] jira-2008-11-14a [ 88672 ]
Sue Linden made changes - 13/Nov/08 04:54 PM
Workflow jira-2008-11-14 [ 88672 ] jira-2008-11-14a [ 94758 ]
Sue Linden made changes - 13/Nov/08 05:02 PM
Workflow jira-2008-11-14 [ 94758 ] jira-2008-11-14a [ 98070 ]
Sue Linden made changes - 13/Nov/08 05:13 PM
Workflow jira-2008-11-14 [ 98070 ] jira-2008-11-14a [ 102057 ]
Sue Linden made changes - 13/Nov/08 05:32 PM
Workflow jira-2008-11-14 [ 102057 ] jira-2008-11-14a [ 109421 ]
Sue Linden made changes - 13/Nov/08 05:54 PM
Workflow jira-2008-11-14 [ 109421 ] jira-2008-11-14a [ 116802 ]
Sue Linden made changes - 13/Nov/08 06:09 PM
Workflow jira-2008-11-14 [ 116802 ] jira-2008-11-14a [ 122447 ]
Sue Linden made changes - 13/Nov/08 06:32 PM
Workflow jira-2008-11-14 [ 122447 ] jira-2008-11-14a [ 131009 ]
Sue Linden made changes - 13/Nov/08 06:49 PM
Workflow jira-2008-11-14 [ 131009 ] jira-2008-11-14a [ 137467 ]
hibit Spad made changes - 14/Aug/09 02:14 PM
Link This issue duplicates VWR-1058 [ VWR-1058 ]
hibit Spad made changes - 14/Aug/09 02:14 PM
Comment [ This issue is also related to: http://jira.secondlife.com/browse/VWR-1058 ]
hibit Spad made changes - 14/Aug/09 02:16 PM
Link This issue Relates to VWR-1058 [ VWR-1058 ]
[ Permlink | « Hide ]
hibit Spad added a comment - 14/Aug/09 02:20 PM
The channel that this might free up could conceivably be used to hold collision plane information.

hibit Spad made changes - 14/Aug/09 02:20 PM
Link This issue Relates to VWR-12171 [ VWR-12171 ]
hibit Spad made changes - 14/Aug/09 02:30 PM
Comment [ I messed up and entered this as a duplicate when I meant to enter it as being related to. ]
hibit Spad made changes - 14/Aug/09 02:30 PM
Link This issue duplicates VWR-1058 [ VWR-1058 ]
[ Permlink | « Hide ]
TigroSpottystripes Katsu added a comment - 14/Aug/09 02:46 PM
What channel that would be freed up? what are you talking about?

hibit Spad made changes - 15/Aug/09 01:40 PM
Description the idea basicly would be to instead of having sculpty being a separated type of prim, enable any of the old types of prims to look like a sculpty while still having the parametric collision mesh of regular prims


for example, one would make a pretty sculpty chair model, and have the system think it is a path cut box ( so avatars and phys objects would not only colide with the legs of the chair as expected, but would also colide with the top of the seat and the back of the chair aswell), stairs could look like having several steps, while stilll being seen as a ramp by the phys engine using a single prim, one could make an intricate looking cave entrance, and have the system deal with it as if it was a stretched torus, you got the point


the sculpted look would be an option, perhaps somthing like the flexy option, perhaps in a separated tab, and would have it's own parameters regarding position, rotation and scale, to allow the custom shapes to be more easily aligned with the collision mesh

to not break existing content, old sculpties would be converted to prims of the proper type (the default sculpties would be spheres, the ones with torus topology would be torus, the plane would be flattened boxes etc), so for example, the default apple would be a sphere with the appearance of an apple. as for scripts, I'm a bit unsure if there would be a clean way of having backward compatibility, but it shouldn't be too hard to make it not break most of the current scripts 		the idea basicly would be to instead of having sculpty being a separated type of prim, enable any of the old types of prims to look like a sculpty while still having the parametric collision mesh of regular prims


for example, one would make a pretty sculpty chair model, and have the system think it is a path cut box ( so avatars and phys objects would not only collide with the legs of the chair as expected, but would also colide with the top of the seat and the back of the chair aswell), stairs could look like having several steps, while stilll being seen as a ramp by the phys engine using a single prim, one could make an intricate looking cave entrance, and have the system deal with it as if it was a stretched torus, you got the point


the sculpted look would be an option, perhaps something like the flexy option, perhaps in a separated tab, and would have it's own parameters regarding position, rotation and scale, to allow the custom shapes to be more easily aligned with the collision mesh

to not break existing content, old sculpties would be converted to prims of the proper type (the default sculpties would be spheres, the ones with torus topology would be torus, the plane would be flattened boxes etc), so for example, the default apple would be a sphere with the appearance of an apple. as for scripts, I'm a bit unsure if there would be a clean way of having backward compatibility, but it shouldn't be too hard to make it not break most of the current scripts
[ Permlink | « Hide ]
hibit Spad added a comment - 15/Aug/09 01:54 PM
This would add a lot of options for builders in SL. I would like to suggest that an optional file or perhaps a layer of the sculpt texture would hold the data for the collision planes. The program routines for the collision plane and its manipulation already exist. All this JIRA is asking for (or at least all I am asking for) is access to the routines and the data set so that the collision planes could be manipulated to more closely match the sculpty. Surely a minimal amount of coding would be required to make this happen.

[ Permlink | « Hide ]
hibit Spad added a comment - 15/Aug/09 01:59 PM
I am sorry TigroSpottystripes, I linked this JIRA in with VWR-12171 and when I did I left a comment on that action. I did not realize (because I am a noob) that the linking and the comment would not be tied together when people look at it.

[ Permlink | « Hide ]
TigroSpottystripes Katsu added a comment - 15/Aug/09 07:02 PM
I'm not sure I understand you right, are you suggesting that a custom collision mesh would be stored in the alpha channel of the sculpty texture? how? And why does hiding the sculpty map would be related to using regular prims as the collision mesh for sculpties?

If I'm understanding you close to correctly, I think you should make another pjira entry about your idea, it seems to be quite different from my own suggestion here.


[ Permlink | « Hide ]
hibit Spad added a comment - 16/Aug/09 12:04 AM
Perhaps I misunderstood your intent.

Let me try to sum up what I thought you were saying and see if I understand what you are proposing.

You are talking about taking the collision mesh or planes from a standard prim that everyone used from day one and combining this with a sculpty somehow so that collisions are hopefully more customizable to the portrayed sculpty.

There are a couple of more detail that you suggest but assuming that I understand the essence of what you are proposing,
yes I am saying that the possibility exists that we might be able to use one of the unused layers in the sculpty graphic file to store the data on the shape of the collision mesh for the sculpty. Since I am not really a graphic person I don't know if this is feasable. but if it is feasable then the suggestion of hiding the sculpty texture would go towards making the suggestion workable. Killing two birds with one stone.

Once again, assuming that I understand the essence of what you are proposing, all I am suggesting is a possible alternative to get to the same end point. I had hoped that the discussion would mean that the final goal would be moved along closer to implementation. It was not my intent to hijack or derail your idea. If you still believe I need to file a different JIRA I will do so but I thought that what is happening here is a discussion about the same final idea with possibilties of how to get to the end result occuring.


[ Permlink | « Hide ]
TigroSpottystripes Katsu added a comment - 16/Aug/09 08:45 AM
I dunno if there is enough bytes in the alpha channel of textures to store all the prim data, and there is also the problem that currently we can't edit textures after they've been uploaded.

But from what I understand, there is ways to have additional prim parameters even a whole new texture slot and a second set of position rotation and scale parameters.

If your idea is possible, it instead of freeing up the alpha channel, it would use use it up and probably would prevent the collision mesh of a sculpty from being tweaked further after the texture is uploaded
Powered by Atlassian JIRA the Professional Issue Tracker. (Enterprise Edition, Version: 3.13.2-#335) - Bug/feature request - Atlassian news - Contact Administrators