would it be too hard to make this also work for spheres, toruses (torii?) and company?

Sculpted prims got lucky because they retain their shape even when you change the path shape.

Also, I hope you realize that this will open many doors in the adult industry

Qarl:
I know with hacks alot can be implemented, but this does show basic code level support for flexi sculpts... perhaps now is the time to push forward on bones and Flexmap/Skinweight channels.

My reasoning is, if everyone exploits like this and these prims are out there, we may not be able to back-peddle. of course, a Flag for Flexmap/standard Flexi would be useful.

OOOoh.. I would so like to see flexmaps by Halloween... Some of the Chain Sculptmaps would be perfect for this tech! though, even Christmas with beards and bells on harnesses would be nice too

http://78.47.71.225/FlexiSculptView121.rar

for testing

Feel free to make download mirrors (I'd appreciate that)

p.s. Just unrar and run it. no need for an actual installation.

It was made by Zwagoth Klaar, Kristie Young and Uchi Desmoulins

Read the description :>

All cudos to Zwagoth, Kristie, and Uchi as it's about time someone force the hand

i plan to investigate thoroughly - but i'm busy for the next couple weeks. i'll keep you posted.

in the meantime - here's a concern:

when textures are downloaded to the viewer - they are immediately shuttled into VRAM. to "sculpt" a prim - this texture is temporarily loaded back out of VRAM into the CPU, where it's used to create the shape.

currently - this only happens when a sculpt rezzes or changes LOD. but for flexisculpts - this is happening every frame. and that's no good. so we'll need to find some (good) way to cache this data in the CPU (either the texture itself or an undeformed mesh, not sure.)

I noticed this, it was a concern of mine for the final patch, but I was looking to implement the feature before tackling the issue of this performance problem. Working from the existing flexible subsystem was a design goal so that things behaved similarly.

It might be noted that normal flexibles are regenerated from scratch every frame, so it might be worth my time to redo a bit of the framework for them, so that they are a bit less intensive on the system.

Some other things I may or may not try to address is that in a sculpt, the Z offset of any pixel can be considerably different from the ones after it. In a normal flexible, you have a very well defined, line path, with predictable Z increments. The resulting effect of this "chaos" of Z offsets in sculpts makes for very odd transformations when something has multiple points at a specific height, but at different x/y coordinates. It effectively breaks the illusion that the shape is really bending, and more that its being sliced up and pushed around(This would be perfectly accurate for how it is currently done.)

There are a few ways to address this, but they are somewhat unfeasible for real-time purposes.

The inability to scale these things is driving me right batty, because I can't locate a logical reason why they would not scale. They run through the same transform matrix as any other flexible prim would, and its applied to the final shape. If anyone has any insight about how the scaling transform process applies to shapes, and the exact order that its run in, please, let me know. Until then I will dig my way through the code until I come up with something useful and can fix this rather annoying pitfall.

Once that is addressed, I will work on and address the performance concern of both flexibles, and sculpted flexibles.For the moment, they have a slightly higher performance impact than normal flexibles, but are still governed by the time limits that can be set by the user. They shouldn't cause any more "lag" than other flexibles because of this, the updates are just throttled.

I would go with storing the unmodified vertex data, it should be faster to use than having to run the sculpt algorithm on a in memory texture every frame. It should use about the same amount of memory either way.

lag

Before we jump off the cliff and inundate SL with flexible sculpties... maybe we should check into whether the system can handle it technically. I'm as much for it as anyone else but already flexis and sculpties are both two of the most lag-inducing constructs on SL. It only makes sense to ask what will happen if we mix the two together.

Before I give this my vote... I'd like to see the stats:
1) Standard prim performance
2) Standard flex performance
3) Standard sculpty performance
4) Comparative of flexi-sculpty performance

Once we see those states, we might better judge whether this is a good idea or not. SL is already lagged to death. I think a good test might be the (what's it called I can't remember... measurement tool for avatar system requirements). Anyhow, use that tool, measure an avatar wearing 10 flexis, then 10 sculpties, then 10 flexis sculpties. See what happens.

For a fair test they should all of course be relatively the same shape and size. However, there may be far better ways to test than that. I'm not a graphics tech, I dunno. But surely would need to be tested.

If they pass the test, I'm all for the idea (especially since someone already did all the work).

I'd like to believe, that in the process they would also take the sculpty OUT of the normal rendering path and allow it a better LOD function/priority/caching/etc...(slightly overdue? /me pokes Qarl)

In the long run, this feature may fix both the problems with Sculpty lag and Flexi lag.

on a side note, with sufficient hardware, comes very little impact. Always the scapegoat, but I don't like the idea of having my investment gimped because someone else's laptop is insufficient.

This flexi implementation would really probably classify as a viewer hack. (as could be argued for flexi AND sculptys as well, but lets not) I see this feature request as a way to 'light a fire' under the need for advanced features that people are looking for currently. I'm all for viewer skin changes, but the push for that was just so people could get the old one back :/ this feature would help with the quality of the experience in SL.

/me steps down from standard prim soap-box

Obvious benefit being the ability to allow the client to use the video card to LOD the object, but the update/transfer overhead has to outweigh the gain of having the process farmed like that. besides, with more specific algorithms for LOD, we could have more intelligent Poly drops that don't trash complex shapes (chains, leaves, furniture, railings, etc...) I'll be surprised if a feature like bones or multiple attach points is possible until it's pulled off card, let alone flexmap/skinweight

The reason I even started this project is because Uchi showed interest in the idea, and I wondered how feasible it was. I wrote it to prove it could be done, mostly to myself.

I think that Qarl is the wrong person to poke about LOD functions, they are written over time by a larger number of employees within LL, as a joint project, some of the code in the viewer dates back far into 2003. This brings up a lot of other issues, about how it maybe should be reworked and started up from scratch to take advantage of both things learned over time, but also to take advantage of newer technology and methods that have been founded since then. When the project was started it was easily state of the art, and pushed the technology edge in both graphics and infrastructure. It has since outgrown the initial design many fold.

In the run of its discussion and evolution it has brought up a great many performance claims as well as issues with current implementation, some of them should be addressed more for the good of the entire rendering engine, while others are specific to this feature. I am a bit torn as to if I should put this specific feature on hold and investigate some lower level graphical performance issues, or if I should continue along with this project, and then maybe look at those issues afterwards. Either choice has pitfalls and advantages.

Lex Neva:
I removed my earlier comment because it overstepped being a friendly comment, and had turned into a personal attack, something I think never should have been posted here, both in professional sense, but also out of respect for others opinions. I sometimes forget that not everyone has higher end hardware and machines that can support some of the newer features that give large performances boosts to features such as flexibles and sculpted prims. The more technical information it contained, I cannot verify to be absolute accurate, and never should have been posted in faith of being true. I would like to apologize for having posted it at all.

Performance:
Yes, the current sculpty/flex implementations are laggy. but, the problem lies in many of the legacy methods they are fighting against even for physical existence! (LOD) Very aware that Qarl isn't the only person at linden labs, but to find a good place to start, he's the guy for sculptys. looking at his work-queue, he's over most of the jiras relating to them. My frustration is that everyone seems to burn so much time streamlining the broken functions, instead of stepping back and saying... "you know that's broken, lets do this" It's breakthroughs like THIS PATCH that allow for out of the box thinking that bring stuff like sculptys into existence!

DO NOT TAKE ME WRONG. this has stirred up interest in innovation that has long since been dead in these forums! one or two detractors stating performance issues... shesh! 300+ who think it's an amazing idea!

The open-source Viewers are already passing us (REX and alternate character meshes), lets keep the innovation going in the main grid!

So, for the moment, people wanting to create sculpts for this, should keep their exports above the 0,0,0 center of the sculpt frame, or it will not behave correctly. Objects flex along the Z axis, keep that in mind.

http://www.slexchange.com/modules.php?name=Forums&file=viewtopic&t=55763&postdays=0&postorder=asc&start=30

Don't worry, its a cross platform change.

If you are lucky, somebody will compile a version of the client for mac that includes this patch for testing purposes. Otherwise, you will have to wait until/ / if it gets added into the official client. Judging from votes and overall response, it seems almost silly to think that it wont happen. It may be a few weeks before it happens though.

There are TONS of objects like plants, tails and hairdos that use 5, 10 even up to 50 flexible planes or cones which could all be reduced to ONE flexible sculpty!

Ok in reality a 6 flexi tail could be reduced to one, a plant from 10 down to 2-3 and hairdo of 50 down to maybe 5. And of course they would all look 100 times better in the process. That would be a HUGE improvement on the current situation assuming the CPUload between sculted flexis could be made the same as non sculpted.

• currently it is up to patch 0.5.1, not 0.5.2, so there may be scaling problems.

• To fully use it, extract the rar file into a new folder, then copy

llkdu.dll
the 'fonts' folder
the slvoice*.exe files
vivoxsdk.dll

from your normal installed viewer into the extracted folder. Run secondlife-bin.exe

What's happened since? Nothing. The whole idea of having this has been quietly swept under the rug and ignored.

This feature's dead.

ok - here's the thing. in order to use this patch, two things need to be addressed:

one, the texture readback from openGL. as noted (here? maybe elsewhere) the current implementation causes MUCH lag... and this is the reason. it needs to be cached on the CPU somehow (maybe as the raw texture, or maybe as the un-flexed sculptie mesh. i dunno.)

two, it needs to be tweaked so that it works better for ALL sculpties. the current flexi-code assumes that the flexible spine runs straight-up the z-axis. with a little cleverness, it could be taught that the spine runs between the poles of the sculptie. (or maybe there's an even better solution. again, i dunno.) but right now, most sculpties won't flex the way you expect.

so flexi-sculpties require more work. and LL right now is in no mood to work on unplanned features - we've become MUCH more disciplined about what we work on (for better AND worse.) so.

absolutely - if the community wants to fix the patch so that it handles the two problems above - that'd go A LONG way toward speeding up the process. otherwise..... it's on hold. sorry.

http://jira.secondlife.com/browse/MISC-1494 - Importable Meshes survey

And yes, I understand that it needs work, that it isn't ready in its present form. And no, I don't think leaving 100% of the work to the community and then, only by LL's discretion, adding it or not is reasonable at all. Is requesting and pushing for features through the JIRA the most futile thing in the world?

The community wants this bad.

it's out of my hands ATM - but i can pester the person who's hands it is in, and see what the verdict is for priority, time frame, etc.

Currently flexibles are implemented where their verts are calculated each frame(kind of) on the cpu. The prim geometry generation code is fairly overhead intensive, when combined with the pull of image data, I do think it will be a serious problem.

The idea I have, is to move the flexibles system over to a vertex shader. It is both faster, and requires almost no cpu side generation of verticies as you can pass the vertex shader any geometry you want. This also opens up other possibilities as there is no specific shape limitations behind them that way. One can also upgrade the flexibles system to use a tiny texture as a flexible map, and move it into a 2D mapping system instead of a one dimensional spine.

Avatar mesh is done this way. But, I have not had the time to fully understand how it manages this. (They surely made it REALLY confusing from a code perspective what goes on.)

I propose including a preference that will allow the user to let flexible sculpties to remain rigid on the viewer. This could help those with older hardware reduce lag and chance of crashing.

i'm beginning work on this starting monday. it won't take long - but it WILL take a long time for it to reach our released viewer. i'll put the code into one of our publicly available branches, so the hackers can play with it early (and maybe provide viewers for the non-hackers.)

the code still needs a GPU readback cache - that's being done by another Linden as a part of a different project - which will take quite a bit of time to complete. i'll try to get you an estimate of when you can expect to see it in a released viewer - but don't look for it anytime in the next few months - we've got a lot of work in the queue.

although, if someone with coding chops were to take this patch and build it - i think you'd become an instant hero in the community.

I'll try and merge this into a compiled version ASAP!

(BTW, whats a good way to get ahold of the nightly viewer builds to base on?)

Thanks!

I noticed the default patch would only do 8x8 sculpties when flexi, But with some messing around I was able to make it work with the regular 32x32 sculpts, When this hits the main viewer will it only be 8x8s, Or will it show higher quality ones?

with 32x32 sculpts: http://www.youtube.com/watch?v=xTQgb7x_now

flexis are a SERIOUS load on our rendering engine. normal flexis only get 8 verts... and that's what we decided to do for sculptie flexis too. so now we need to figure-out what to do from here... i'm open to suggestions. (i completely understand the desire for more detail... that video is awesome.)

i agree - a vertex shader solution would be ideal. sadly that's a bunch more work. i know Zwagoth has been threatening to do it. AND Runitai (Linden) has explored doing all flexis on the GPU - but you'll have to ask him why he gave up. (maybe an issue with compatibility for the physics?)

(and as an aside - maybe it's simply better to multi-thread this stuff and rely on additional CPUs. i know Runitai was been working heavily on threading...)

i think we'll end-up providing a debug setting to turn-up the maximum for people with honken-CPUs. i think we might get pushback if we try to make it a full preference - novice users play with those settings without understanding them - and then they have a horrible experience.

In case anyone wants to toy around with this in a viewer, I've applied the latest patch to Imprudence:
http://imprudenceviewer.org/2009/02/23/just-for-fun-flexible-sculpties/

(sorry for the downloads being Windows and Linux-only. We need a mac dev!)

Questions/Suggestions

"8 verts for flexi"
That refers to the underlying bone-structure, i guess ?
8 consecutive bones and flexi happens at the "joints" between them ?

So we will have some extra settings for flexi as prim-settings, that seems inevitable.
Will there also be information encoded in the sculpt-texture ?

I kinda see 3 different approaches as possibilities:

1. no flexi-information in the sculpt-texture ... everything as extra-settings

2. alpha-layer of sculpt-texture is being used to assign a vertex to a position in the bone-strip (0 is the start of the first bone ... 255 is the end of the last bone)

3. the bone-structure is saved in the alpha-layer ... not value-per-pixel ... but as meta-info like a watermark.

Please correct me if any of this is non-sense.

Since current sculpt maps were never uploaded with the intention of being flexible, I don't believe it would be considered breaking content if those maps were not readily available to support custom spines. All current maps, wither they had no alpha layer at all or used it for watermarking, could not use a custom spine; so an option to not use the alpha layer for a custom spine would be mandatory. This way you can still use the alpha for watermarking and use the default color-average bone line for old sculpts, or, if you wish, new ones.

But let see that in another way. You want to define custom bones/weight map for sculpties. Why stopping on sculpties ? If you choose an external way of defining it. You also can apply to basic non-sculpted prims. Wouldn't it be better? Choosing to put those "settings" on the alpha layer you stay stucked to apply it on sculpties only.

Question: Could this new system allow to have basic flexy torus, spheres, tubes, etc. prims ? I believe so. Making a more generic algorithme is better.

TYVM!

Furry AV builder
Shannon Lean

Ta

gianna Zapedzki

already in this thread we're seeing push-back against spending too much CPU on flexis. and that concern is warranted - flexis currently take-up a HUGE amount of our per-frame cost. even once we provide a slider for 32 vert flexi-sculpties, you can believe we'll ship with 8 as the default, and MANY people won't venture past the 8 limit.

A fixed mapping, to a fixed bone-strip (Z-Axis), with a fixed relation to a reduced 8x8 (fixed) sculptie.
That seems to worst possible way to me.

I see that the fixed bone-strip (Z-Axis) might be hard to avoid.

But alpha-bone-mapping would make it so much more usable and adjustable.

Without unlinking the mesh-size from the bone-count, it is even hard to determine if the current bottleneck is more along the lines of:

"Flexi-Physics on a long bone-strip is too much computational load"
or "Dynamically changing geometry cant be compiled to OpenGL display-lists for fast rendering"

The complaints you are seeing about detail on flexi-sculpties are not like "We must have a long flexi-bone-stip",
they are more along the lines of "We need to have standard sculptie-meshes be usuable as flexi-sculptie".

I think it would be very sad, if sculptors had to threat flexi-sculpties and regular sculpties totally differently. (due to the 8x8 mesh)

"spending too much CPU on flexis" sounds like "Flexi-Physics on a long bone-strip is too much computational load" to me.

Therefore it might be VERY interesting to have 8-Vert Flexi on regular Sculptie-meshes (32x32 and all oblong ratios).

I would love to know, if any of this is non-sense .... because if it isnt, it should be looked at.

EDIT: Here's a video: http://www.youtube.com/watch?v=tfjPUJKjPdw

i'm assuming you mean something like: 8 points for the joints of the flexi-spring system drives 32x32 verts of the sculptie. (which is a variation of BlackBox's idea for bone mapping.)

the problem is: that is exactly what is too CPU expensive to do. it's the recomputation of those 1000 points and pushing them out to the GPU (every frame.) all this animations is EXTREMEMLY expensive. (that's why we have avatar impostors, to reduce this sort of thing.) (yes, BB, as you say we can't use display lists - although we actually use vertex buffers.)

BTW: i love the tail in that video. but i'm confused, isn't it suppose to show unusable flexi-sculpties?

DEF shoot for the GPU if you can since it's more meant to be doing this kinda heavy scale computation. Almost everybody these days, has a decent video card these days, and even if the user doesn't have a decent vid card, this doesn't have to be a mandatory feature, either.

This may be impossible, or just difficult. I have no idea. Haha. Just my two cents. Features like this, and the shadow client, I really think could make suuuge a huge impact to this game, and I'd hate to see them end up never being a part of the client

(Having 36 full-res flexi-apples out in a moderately busy sim brings my FPS from around 85ish to around 35ish, and the flexies begin to not update as fast as they should...
Imagine the usual generic lagatar with a head full of flexi hair, and then skirts or whatever else as flexie sculpts, Not the pretty sight performance-wise)

Vertex shaders would have no problem at all doing the 1024 verts on hundreds of apples with a modern videocard

The first shows two flexi tails, one made with normal flexiprims (4 flexiprims) and one made with a sculpted flexiprim (1 prim). As you can see, at 8 verts the sculpt loses most of its detail. I wouldn't use such a thing in any product. It looks like something on a Nintendo64 game. The second screenshot shows the same sculpt without flexi. Not a perfect sculpt sure, but it's smooth. The "nostalgia look" of the flexi is not the fault of the sculpt.

There's also the issue of smaller details. I should be able to sculpt tufts of fur into that same shape, and have them still be there on the flexi. As it is, if SL's sculpty ability doesn't eat the details, they disappear when flexi is applied.

EDIT: Please don't read any hostility into my posts. I'm really excited about the progress made on this! I'm just trying to point out what content creators are going to expect or want from a given feature.

To be honest, the tail in the video looks great to me. And if we are afforded some configurable sliders as alluded to previously, I thinkt hat would be a good compromise. It can be frustrating, but I think I'd still like to have this as is rather than not at all.

How about we bring LoD into the equation more ?
How about more harsh LoD-settings for flexi-sculpties ?
If we could only unlink the joint-count of the flexi-spring from the vertex-count of the sculptie it would be so much more adjustable.

The flexi for a highest LoD sculptie could be full 8 joints ....
On a lower LoD a sculptie could become non-flexi (locally).

Anything else than a hard-coded, fixed solution with conservative hardware-assumptions would be nice

i am not complaining either ... just saying what i think sculptors will tell you once they are trying to use flexi-sculpties for real.

And even on that note, most people, even the lowest hardware being sold right now, has a decent GPU somewhere in the mix. GPU rendering is an absolute standard anymore, and I think this game in particularly would jump leaps and bounds if was ALLOWED to use it.

I'm also fairly sure SL checks your hardware, and scans it pretty thoroughly, so you could code it to check if they have a decent GPU, or even a GPU at all, and then scale the usage of it accordingly. If you have a good GPU, allow shaders to control the arithmentic and rendering of objects. If it's a weak one, throttle the GPU usage, and use more CPU. If no GPU or 3D acceleration, just stick it all on the CPU.

Like I said before, I'm by no means a profession game programmer, so I don't particularly know if it can work like that. But if it can, that, imo, would be the way to do it. And I'm a firm believer in using the GPU. It's just meant to Crunch numbers. shrug

Obvious questions to ask just so more can grasp what's going on here:
Is the problem with flexing a sculpty something completely obvious like the box physically being a sphere, which can't flex?
Is this in any way related to the reason that the torus, sphere, tube and ring can't flex?
Is the box no more than the physical attribute to the object and has no other bearing on how it looks?
If not, what were the original reasons for making bounding boxes / sculpties work in a separate manner to regular prims?
Is there a chance that reasoning could be reevaluated for the purpose of adding flex?

I found this regarding vertex shaders for physics, maybe something useful to be learned from it http://playcontrol.net/ewing/jibberjabber/waveinterference_opengl_sha.html

http://dl.getdropbox.com/u/51818/Second%20Life-flexi-sculpt.dmg

It has at least worked once Enjoy...

flexi-sculpties are implemented and ready for official viewer integration - however they still require cache work in our texture system (as detailed above.) this work is being done by another linden as he reworks all of our texture system. i think there's almost NO chance of all of this being in 1.23, but a good chance that it'll appear in 1.24 (or whatever we call that version.)

Does it work at all without the cache work? If so, is the code somewhere in the public repo? I'm sure there'd be a lot of people happy to give it a test run and flush out any bugs there might be.

Also, would it be possible to have the 1.23 viewer render flexible sculpts as regular sculpts, instead of as flexible cylinders? That way when official flexible sculpt support rolls out, content creators can start using them right away without a deluge of customers on older viewers complaining that their new hair looks like cylinders. (This seems like it should be a simple tweak to the way volume parameters are processed. I'd happily do it myself if there's a decent chance of the patch being used.)

Danny - no, we just don't have time for a GPU solution now. if someone in the community wants to provide one, well, i'm sure we'd jump at it.

Which would be harder on the client: a single 32x32 flexible sculpt or four 8x8 flexible sculpts?

Would it be possible to have flexible sculpts with 32x32 maps but with only 8 or even 4 flex bones?

If the number of polygons is intrinisically linked to the number of flex bones, could we allow oblong 128x8 sculpts, thus providing greater detail with the same number of bones?

https://jira.secondlife.com/browse/VWR-27

But making a sculptie sort its own faces before it is sent to rendering (which could keep the old behavior of sorting only according to the distance from viewer of the center of each prim, but each prim would sort itself first) would allow llTextureAnim based animation which makes only part of a sculptie visible at a time, the other part being 100% transparent (i.e. load sculptie and texture on it only once, no physical calculations needed as the sculpt creator can pre-compute it with third-party sculptie tools).

This would have the lag level associated with llTextureAnim and not the TOTALLY HUMONGOUS lag of this patch. It would also allow arbitrary animations not just flexi, i.e. grenade explosion... (since it's the same texture just rotated, it fixes a long-standing annoyance with preloading animation frames).

Of course both ways of doing it can co-exist, it would not be too hard to duplicate flexi-type behavior with my method - even if it would have the downside of not showing all the sculptie at once (less vertex at once, but then all the vertex can be animated separately) and no ability to adjust to avatar motions like the common flexi tail, but still it would be another "must have" for animators.

Both of thoose items were quite laggy and would easily shave off several fps, even with my high end machine... And with the flexi's limits, they would appear static, or frozen in place if people use too many in one scene

It's not really a big deal to me, since the feature is almost ready anyway, but I thought I'd post out of curiosity anyway.