|
|
|
This is the best idea I have seen after the lossless upload idea.
The channel that this might free up could conceivably be used to hold collision plane information.
What channel that would be freed up? what are you talking about?
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.
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.
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. 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, 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. 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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
sculpted visuals, and parametric collision mesh in a single prim
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 !