|
|
|
[
Permlink
| « Hide
]
Argent Stonecutter added a comment - 30/Aug/07 07:36 PM
See also https://wiki.secondlife.com/wiki/Talk:Sculpted_Prims#LSL_functionality.3F
 Agreed. There should be plenty of room for these settings anyway as sculpted prims only use a fraction of the available prim-settings (they only store a sculpt-key, position, size and rotation).
I strongly dislike the current system of using media-feeds, as it places reliance on outside sources, and restricts animation to a single parcel, complicates set-up etc. etc. My only thought is that (and llSetTextureAnim() may already support this) we require the ability to drop frames to scale with LOD, ie - as frame-rates get worse, sculpted prims with animations will get less detailed, and update less frequently. So instead of interpolating frames to 'morph' between shapes (if set-up on the animation) the sculpties would eventually snap from frame to frame, or even skip some. I hadn't even considered that we'd expect the client to perform interpolation between the frames. It would certainly be nice, but probably shouldn't be a requirement.
Depends I suppose on the relative cost of caching intermediate frames. Anyone know roughly how much memory a sculpted prim takes up once the texture is converted into a geometry?
I was thinking more of the cost of updating the prim geometry in the GPU. Or are you thinking that each frame would be maintained as a vertex buffer object? Even then, you'd still need to update the list in the GPU for each frame, and adding tween frames would hardly help.
Also, sculpted prims don't seem to benefit much from VBO optimizations to begin with: they seem to have an inordinately high impact on frame rate compared to similarly complex toruses. I'm not sure, but you may have made the same mistake I did initially; sculpted prims are not generated by the GPU. Once the sculpt-map is downloaded it is turned into a 3d mesh (I believe all prims follow the same case, using parameters instead), this is then cached somewhere, and passed into the GPU for rendering as required.
My thinking was that with an animation it's a case of generating all the meshes as you go through and keeping them cached, so that the second time around an animation additional frames can be generated, or evem tween frames as required (and if performance is good enough). Keep them all cached and you can have some pretty smooth animations, since loading an already generated mesh onto the GPU shouldn't be very costly. Especially if you consider that a media-stream cannot reliably cache the meshes that it generates as it doesn't know that the stream won't change, and thus is generating "new" ones every single time. So, to keep things performing well enough you generate the meshes only as quickly as performance allows, so an animation may be a little choppy the first time through, then get smoother as the work is completed and more frames are cached in memory (or virtual memory if out of view). Sorry if I'm over-complicating things, but I do believe that an animation system, with or without tweening is very much technically feasible; yes, it may be hard to believe but that's what my raving drivel was trying to say =) No, I'm not assuming they're generated by the GPU. I was thinking that maybe you were, or that you were assuming that they could be cached by VBO... it seemed that you were neglecting the cost of updating the mesh for every frame when doing intermediate frames, rather than simply updating the mesh when it's time for a new frame to show up.
Whether VBO is used or not is really independent of where the mesh is generated. And I agree that skipping frames is entirely viable. And I just thought of something: another problem with tweening is that the corresponding texture animation for the surface texture isn't tweened, so the tweened frames would have baked shadows and surface detail in the wrong place. That depends on how you're animating I think. As it's entirely possible to have a sculpty animation that uses the same texture for all frames anyway, it'd be a bitch to make sure, but means you can have a better or lower res texture for the whole thing, rather than needing one per frame (I'm assuming you're referring here to having llSetTextureAnim() and the sculpty-based function synced?). Texture frames can also be interpolated quite easily:
For the cost of intermediate frames; easiest way to do that is just to "average" the image, ie - if you're doing 3 intermediate frames then you would do the pixel value of the first image multiplied by 0.75, plus the pixel data of the next frame multiplied by 0.25. Then the same with 0.5 and 0.5, then 0.25 and 0.75, then you hit the new frame. It's the same as generating a normal sculpty, except that two sets of image data are fed in with a 'balance' to tell it how much of each one to use. I will admit though; tweening should by no means be a priority. Even very basic frame-by-frame animation is a huge step forward. Of course there would be one sculpt texture for the whole animation, along with a matching surface texture, and both would be animated with the same parameters. Since texture animation is started when the prim comes into view, it would probably take some effort NOT to have them both in sync.
I don't have any misapprehension that tweened frames would be complex or expensive to implement, compared to having the same number of frames explicitly encoded in the texture. All I'm concerned about is the higher frequency of updates to the mesh that tweening would require over simply playing the frames provided. Looking at the sculpted prims discussion page (https://wiki.secondlife.com/wiki/Talk:Sculpted_Prims
), it seems that Qarl is assuming this feature would be used for lengthy animations. The animations and transitions I'm envisioning, even without tweening, are only going to be half a dozen frames long at most: most existing texture animations are around 4 frames, and almost all are less than 16... about the only lengthy "movie" I'm familiar with is the one of raccoons playing in a pool. Andimated sculpt textures would be likely to be used similarly, with a few stable states and at most a couple of intermediates. Agreed, my main need for these is to animate from one frame to another, and then later do the reverse to transition back. It would be especially useful if we are given some way of switching to individual frames specifically. For example, if my picture is divided into 16 frames, then I can switch to frame 5 and stay there. Possibly a sculpted prim property for x and y frames, plus an option to set the current frame would be easiest? Since animated sculpties will be sampling parts of an image there is no need for offsets and things.
Only other settings need then are looping, back-and-forth looping, animation speed, and optionally interpolation (especially for slow animations). The interpolation I'd still like because it occurs to me that I could send 2 frames of animation and have a simple, slow, smooth animation without needing to send every frame in between. ^^ But yeah, I don't personally see much demand for an ongoing movie type sculpted prim. I do see a need for a looping animated sculpted prim. The point is that this is still not the kind of thing you would use a stream for. For example, the animated dolphin avatar has an 8 loop cycle when swimming, with three of the frames in the middle pingponged when not moving, and 5 extra frames for shaking the head to one side or the other. This is currently implemented by loading the frames on a timer, but it would be better handled with a short texture animation on the sculpt... and less laggy as well.
What is needed is llSetScupltTextureAnim() with almost the same arguments as llSetTextureAnim including the mode. SMOOTH could be used for your tweening, if that's practical. Unsure, I see the need for looping animation, but I do wonder if texture animation is the way to go long term.
I've suggested a skeletal rigging system that would be far easier to animate by script, and eliminate the need for texture animation frames. Don't forget that sculpties themselves are REALLY not the way to go long term either... we want to be able to upload both general meshes and algorithmic surfaces. I think that there's a lot of headroom in sculpties, yes, and VWR-5191 is definitely a cool way to solve a lot of animation issues, but BVH files aren't scriptable (you can start or stop an animation and that's it... you have a lot more flexibility with offset-based animation) and extending animations to additional prim bones will not help animating objects that aren't attachments.
And of course this would be far easier to implement short term, and don't forget the only reason we have sculpties at all was because they were easy to implement. I know sculpties were easy to implement - they are essentially a geometry image of a patch of vertices. Which is nothing more essentially than a progressive mesh.
a skeletal rig COULD BE scriptable, it's just not made to be that way, yet http://wiki.secondlife.com/wiki/Puppeteering A succession of textures or meshes is far larger sizewise than the same succession of BVH frames telling the mesh where to move when. Always has been, always will be. I know about puppeteering. I also know about other plans that they have to use sculpties to replace the avatar mesh. But that's all really long term stuff, and not in a good way. it won't be in 1.20, or 1.21, or in 1.22. It may not be ever.
THIS is something that could be in 1.19.2, could have been in 1.18, and it's not something that will prevent skeletal animation from happening, so you don't need to point out that it's not perfect. If Linden Labs waited for perfect there wouldn't be a Second Life at all. The idea is really interesting and the feature highly desirable, but there is one more caveat I haven't seen mentioned so far: Loss of accuracy due to compression in the texture file. After making enough noise it was possible to have lossless compression for small textures, which is targeted at sculpties. But if you now make one large texture with your animation frames as tiles, lossy compression will kick back in, and possibly the more the larger your format (not knowing the exact algorithm and its impact atm).
With planar mapping a 32x32 sculpty should be precise, which allows loops up to 16 frames long in a lossless 128x128 texture. A more generally usable (because of the fencepost problem) 64x64 sculpty could have a 4 frame animation with the same 128x128 textures. If 256x256 could be lossless, then you can have 16 frame loops with 64x64 sculpties.
16 frame loops are more than adequate for most purposes, and 4 frame loops are already widely used for facial animations, so I think there's enough headroom. I'm one of the nutballs asking for streaming media to be able to animate a sculpted primitive, but that doesn't obviate this request; in fact, I think they complement each other. Recurring, cyclical and repettive animations are best suited through this function, where 1-off, media-driven, real-world-reflective sculpted prims are best suited to a media stream from an out-of-world source. I vote it up!
Tiling sculptmaps is a shitty idea, except if thats the only way for preloading a shape-animation, wich is just is not, not even right now.
But if you take one sculptmap and blend it over another sculptmap with a given % of transparency and save that one as a tween-sculptmap you have just created an in-between frame. so we just need a texture preloader much like llPreloadSound (not just for sculptmaps) and the option to blend from one shape to another with a set speed, and be able to pause the blending. Seems to me that the blended sculptmap animation is one possible interpretation of the animation texture. There's no reason why a 16 bit or even 32 bit flag couldn't be used for the function as-a-whole, so we could have an alpha channel specify 2D spring flexies vs some other 8 bit value (or 2x4 or 4x2 bit values depending on the flags used --or individual flags per vertex for that matter).
Also, worries about large texture downloads might not be as big a concern if you're using the CAP-based texture connection. Even a 4MB 1024x1024x4 animation map isn't a showstopper if you have a dedicated channel for textures and another for higher priority data (including, if need be, smaller textures). Tiling sculptmaps is no more of a shitty idea than tiling animated textures. And this has nothing to do with tweening (that's a side-issue), and it's only marginally related to preloading: the point to texture animation in SL is that it's client side. A texture animation will run with correct inter-frame timing without any further real-time response from the sim... just like an avatar animation will... which is VERY important on a network with no guarantees of latency.
If you're concerned about the lack of interframe optimization, that's a separate issue. Animated PNG would be ideal for the purpose, and would be a more than adequate implementation. Tiling, however, is completely appropriate as a fallback. would this fix a problem thats a real killer for me currently animating sculpts? the center of the object is refigured for each sculpt map, and so the object flails widly about when animating. maybe thats a separate issue- being able to lock the center of an object. but it really limits the way an animated sculpt can be used with other prims, and if its not addressed with this function, animated sculpts will be of limited utility now matter how they are implemented
Getting the sculpt textures themselves to fit in a shared bounding box instead of having a new bounding box for each frame... that's a function of how you build them. I don't think there's anything that could easily be done in SL to fix that after the fact.
its not really in how you build them. for instance, i made an animated swimming shark. the the width of the bounding box changes as the tail moves. you cant do much about that. so when the shark swims in world, the whole fish moves from side to side. look at any swiiming fish animated sculpt on slex, you will see what i mean. and any prim you link to this looks rilliy as the sculpt map undualtes around it. if this isnt addressed, any animated sculpt map is gonna have a really limited usefullness.
It's exactly in how you build them. There's no reason you HAVE to have the points fill the whole range from 0 to 255 in X, Y, and Z. If you combine the bounding boxes of all the frames into a single bounding box, then scale the individual frames within that box to the subset of that box their own bounding box encloses, the animation will work correctly.
Aah... I had asked that very same question on the sculpted prim wiki page. While I did receive some valid answers none of the suggestions lead to an usable work around to the bounding box issue. I have discovered a technique that solves this bounding box problem so I will share it here, in hopes that LL (or some motivated user) will use this knowledge to create a solution that will work for everyone:
Solution: 1) Create the sculpted object using NURBS. The Result: When you export each frame of the animation it will no longer have wildly different bounding boxes. Each frame's bounding box will match the Polygon plane dimensions. The Polygon plane will not appear in the finished sculptmap. Conclusion: This technique could be added to the Maya sculpty export script to allow multi-frame sculpty animation without the bounding box issue.
I guess that's a quirk of the sculpty exporters that you're using: they automatically generate a bounding box and rescale the sculpt to that bounding box. The Wings 3d one I use doesn't automatically rescale the sculpt map to the bounding box unless you do that explicitly before exporting it, and of course I have full control of the sculpts I create programatically.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Need SIMPLE, straightforward, CLIENT side sculpt texture animation.
I refer to the physical avatar that is a proposed project of LL. If they do that for the avatar, they can do it for sculpties, too. This of course means that we need a better way to link meshes together of course. I hope to see some improvements come down the pike once Havok 4 is solidly in place, in regards to things like joints.