Complexity
The Lab’s solution to simplify clothes making was to publish UVMaps, clothing templates, that most SL users could use. We are starting to see that with mesh clothes too. People are selling a basic skirt, blouse, or jacket mesh with a template as a full perm kit. This allows the current clothes making processes currently in use to be used with new mesh products.
I think what Drongle is getting at is the use of Morph Targets will keep much of the complexity out of the basic process, so kits can be made that are much easier to use. So, just as we make use of the SL System Skirt we will be able to make use of the various kits available.
I am not sure Morph Target do all that much to make the creation process easier than it is now. But, fit and sizing problems will be reduced. It also creates levels of creation, which I believe is important. Basic clothes making will remain pretty simple and mostly a Photoshop effort. As people choose to learn more they can advance to a relatively simple level of mesh clothing, relying on the Deformer. Later they can move on to a more complex Deformer + Morph Target style. At least that’s the way I see it now.
So… marketing-wise we will have mesh and Deformer rigged mesh, and then eventually mighty morphing power jeans (thanks: Typhaon Nishi). And… Elie Spot sort of owes Max 5 billion Lindens. (You had to be there for that to make sense.)
Animation
Currently animation, morphs, and the armature (skeleton) all work together. The general impression I get from the Lindens is adding bones is a temporary hack and they would rather move toward custom skeletons. But, such work would be a ways off for the Lab.
Custom skeletons would be great and is like what we see in Cloud Party now. This idea, even if far into the future, would seem to put the use of Collision Bones (Redpoly idea) on a back burner.
A complication with added bones and custom skeletons is how to decide which animation can be used with which skeleton? If you add tail-bones, what does a tail animation do when it is used with a skeleton without tail-bones? Or with a skeleton that doesn’t have bones the animation is trying to animate? Some means of tying animations and skeletons has to be decided on. And if we sell animations and skeletons separately how do we keep noobies from messing up and using the mismatched animations? Never mind how we would try to explain that to them.
SL Group
Geenz is going to add an SL Group for in-world chat on the CIG issues. I hope to hear more about it at the next meeting. Just what I need, another group. Did you know N-Core Group has 40k+ members? (You can see group member count in your profile on the web.)
Modified Build Panel
An agenda item added by Maxwell Graf was a modified build panel.
Build Panel Concept by Max Graf
Max was getting feedback. He created this idea in response to requests for new features for the Build Panel. Think: ‘New Edit Features: Thumbnails & Gradients’.
Max said, “This would basically allow thumbnail sets to be used for textures and colors, based on folders in a new inventory folder type, or by selecting just a folder of textures. [It is] very helpful if you are doing a build where you need things over and over, similar to an organizer, but built into the UI tools.
The layout of this as I have it here [in the image] is very much just concept. The stuff below it could easily be re-organized to get more room also, like if we need material maps also later.”
In a general way several people are looking at ways to simplify the Build Panel. Niran’s Viewer has tried some variations. While Niran’s Build Panel is a bit disorienting at first, I think it is well designed and reveals improvements are definitely possible.
The Lab is resistant to changes in the Build Panel and certainly to additions. I think the resistance is mostly due to translation problems. Try installing a version of the viewer in German and check out the Build Panel. It may give you a whole new appreciation for interface design.
Improving the Build Panel is possible and a worthwhile effort. Oh… and did you notice the mention of a materials system?
One of the most often brought up improvements is being able to move panels out of the main viewer window. I would go for that. I keep thinking the user interface panels are a major impediment to better FPS performance. Separating panels out of the main viewer might make for a big improvement in several ways. I’m not sure what the technical issues are that have prevented such a change.
Summary
I’ll say the group is interesting… Drop by Hippotropolis on Tuesday at 3 PM SLT/PT. See: CCIUG
The main designer of the past attempts to make a multi-headed client (which is what your referring to when you mention the ability of moving the panels outside of the main viewer is) was Jonathan Ballard aka Dzonatas Sol. The feature is known to Oz and others as SNOW-375 , although it hasn’t been worked on since Snowglobe 2.0 (predecessor to Snowstorm/SLV 2.0) and was lost during the incorporation of Snowglobe into Snowstorm. Ballard’s blog, Icesphere, has a nice description of SNOW-375 : http://icyspherical.blogspot.com/2010/07/overview-snow-375-is-api-to-snowglobe.html
Thanks for the link and comment.
Pingback: Understanding the Infrastructure | Virtual Vision 2020
creating windows that can be dragged outside the main is not done in games bc of how the windows manager on the OS works. like each OS have its own way of doing them. in the QT docs/tuts is examples/chat about all the gotchas for each of the OS targetted. is quite a lot of them so have to make a window layer framework that can work ok on all. is heaps work that
+
main problem tho is that most OS window managers treat each window as a separate process/task as if it was a separate program even. like foreground/background. priority given to foreground. can see this effect in SL. like have SL running and then say open a browser and bring to foreground. can see the FPS hit SL takes when is sent to the background. same thing happens when you have windows in same program and open them. is big hit on the background windows
+
so what games do is only have one window. the floaters and stuff arent like real windows. they just dif draw contexts. this way the programmer has like total control over allocate/prioritise time/resource to painting each context. which cant do if use the OS windows manager to do this
drawback as you say is that a draw context cant be done easily outside of the window device context
is possible to paint/draw direct on the desktop tho and can make your own whole windowing system. but then again you back to making it work on all your targetted OS
Thanks for the explanation. I’ve never tried to write more than a web page for the Mac.
ps
can find a pretty good explanation on how MS windows manager works here. is the overlapping windows that you need to do
http://msdn.microsoft.com/en-us/library/ms632599.aspx