For short I will refer to the group as CCIIUG or, for me, CIG. This week the meeting touched on Cloth Simulation and discussed more about Morph Targets.
For the first 3 meetings the agenda has been overflowing. The topics also require considerable discussion. So, we have yet to make it completely through an agenda in a single meeting. Attendance has been 20 to 30 people.
Part of the idea is to discuss JIRA items that content creators need fixed. Supposedly the first 15 minutes will be devoted to JIRA items. Asking if anyone has a JIRA to bring up tends to result in a ‘deer in the headlights’ reaction. Eventually we may learn to deal with it.
There are a number of JIRA’s that are feature requests and that is somewhat what the meeting is about. It is a bit tricky to use the JIRA to find out what has already been requested and what requests are pending. There are ‘shared search templates’ for the JIRA. It is a somewhat unique feature for a web search, Java SQL thing. Whatever, the handy searches are:
- Popular Second Life JIRA Search Filters – Creates a list of the more popular JIRA searches.
- Open Source Development Ideas – These are things we may see third party developers working on.
- Fix Pending, awaiting public release – This one was added by Torley Linden. As JIRA bug items are fixed they go into QA. It can take some time to get to a released viewer. These are the fixes in that in the QA process.
- All unresolved bugs by # of votes – This one is good for checking if a bug has already been reported.
- My Watches/Votes Recently Updated – This one is good for finding items you are following.
Cloth Simulation
I’ve thought simulating cloth in real time within SL would be a significant lag producer and thus an unlikely addition to Second Life. But, I’m apparently mistaken. Geenz Spad is wanting to look at adding it and brought it up. It is a feature request in the JIRA. CTS-367 – Cloth Simulation was the JIRA item during mesh development. Now it is: VWR-27189 – Cloth Simulation.
Geenz says he is thinking about how to implement cloth simulation. As yet he has not started discussing the topic with any Lindens. Cloth simulation would be good for flowing dresses, capes, maybe even hair.
It looks like this will need to be a client side feature. Our viewers would handle the cloth simulation. So, while everyone would see a swirling dress, the dress swirl would not be identical or in sync in everyone’s viewer. Much as flexies are now.
If you have done cloth simulation in Blender, you know that vertex groups are used to control the cloth. It is a weight painting thing. The hem of a skirt might weight at 100% and the waist band at 0%. The waist would be stationary and the further down the skirt the more swirl. So, this is going to require more information to be developed in an outside modeling program, passing the data out via Collada, picking it up and importing to SL via the SL Collada Importer. Also, additional data must be stored on and streamed from the SL side.
Once the data arrives at the viewer it has to handle rendering the cloth simulation. Physics engines have tended to handle cloth simulation in games because they are optimized to handle collision processing. A skirt collides with the avatar body and legs to avoid passing through. It is some pretty intense calculation.
One has to decide whether to use a third party tool like Havok to handle the simulation or develop one. Havok is proprietary and is restricted to paying customers and non-profit personal use, or something similar… I’m not into the licensing details. There are other third party physics engines that might work. Some are retail offerings and others are free open source. I’ve not been impressed by the open source engines in use in OpenSim. But, there are possibilities.
If you are interested in Cloth Simulation for Second Life, come join the conversation at the CIG.
Materials System
This rumor has smoldered long enough that we are starting to see a glow around it. There may be some fire in there somewhere.
Geenz is saying the affect of materials on cloth simulation should be discussed when it is on the horizon. I’ll take that to mean when the Lab is ready to start discussing it. I take it that some proposal has been submitted and is being hashed out in the Lab. It might still be rejected or put off. But, all the game platforms I know of have some type of materials system. So, I figure the Lab has to add some type of system at some point to keep professional developers interested. I just have no idea where the ‘point’ is in the Lab’s schedule and priorities.
Morph Targets
The Morph Targets idea affects the Mesh Deformer. It seems it is more of a political affect than a technical one. The Lab tends to agree that the Deformer needs to be finished first. That seems to be the general consensus on all sides now. There are a few hold outs for deciding and then moving on one or the other. But, I doubt that is going to happen. It looks like we will do one and then go for the next.
Some worry that the Lab will do one, consider it good enough, and forget Morph Targets. I can’t see that being the case as Morph Targets is going to be developed mostly by third parties. The Lab is now much better at adding third party features.
Proposal
For the Linden process a list of pro’s and con’s needs to be generated. They also like to look at user cases and applications for a feature. Geenz started a document for that purpose and we were editing and adding to it in the meeting. See: Morph Target Advantages. You’ll find this a preliminary level document. It serves a purpose similar to marketing studies that determine if there is a market and its value. Geenz will be asking some Lindens for comments on this document.
After a feature is analyzed for pro’s and con’s and the pro’s are significant enough to warrant further consideration then what’s needed to implement it is considered. Next the pro’s and the implementation costs are weighed. If the result is positive then a proof of concept is tried. If the proof works as expected, a project is started. So, we have a ways to go and this will take some time. So, we need the Deformer ASAP.
Possibilities
There are a number of possibilities for how Morph Targets will work. A checkbox in the upload could allow Deformer Only, Deformer + Morph Targets, or only Morph Targets. It is too soon to start trying to work out how everything will work. But, in general it is believed the Morph Targets and the Deformer can work together. After all, the current avatar as it is now uses Morph Targets and the Deformer works.
Collision Bones
Collision Bones are still a possibility. Bones are used with the current avatar and the Deformer works with them. So, it is technically possible to get all this stuff working together. Whether that is practical or which is or what combination is the best is a future decision for a time when we know more details.
Considerations
Those looking beyond their immediate needs tend to be hitting on the same points. Will Morph Targets make it easier or harder for people to make clothes in SL? Drongle McMahon expressed it this way: “I think morph targets are one approach that can deal with the widely held view that mesh creation is elitist and doesn’t help non-modelers. Morph targets could provide mesh components that are highly adjustable and thus provide a new range of versatile components usable by non-expert people.”
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