Nyx Linden

You've correctly identified one of the projects we'd like to get to post-release! Such a project would include VWR-6713 as you indicated in your other thread. Thanks for the interest in making our content creation tools better!

It is a feature we'd like to get to but mesh doesn't inherently depend on it. It would be a separate project. Feel free to vote it up as an important project for post-mesh work!

In a word: no. As a more complete explanation, the flexi system relies on the fact that prims inherently have a "spine" that we can flex in various directions. In addition, the flexi system is very inefficient (I recently performance tested it to be 5x slower than rendering normal prims under certain conditions). The correct answer to moving and animating meshes is to use a skeletal system, whether allowing custom avatar skeletons (for attachments), or allowing non-avatar skeletons. This is a known feature request, but not one we will have the time to get to before the initial release of mesh.

Hold off until the asset format change (hopefully soon). If objects uploaded with the new uploader fail to rez, definitely let us know. Sorry for the delay

Certainly not hopeless as its a project that's near and dear to me personally! Just not now. We have too many things on our plate, and doing such a project correctly, even if the models & UVs are being community-generated, would take a significant resource commitment on our part to organize the project, choose the best option, integrate the model into the viewer, add support to the appearance editor for a second set of modifyable parameters, etc. It would also certainly help to have some basic materials and a more detailed skeleton. When we get to a point where we're able to commit resources to updating the standard avatar, taking community contributions to the modeling and texure mapping bits would certainly be an attractive option to consider. But there is a lot more work around integrating a new avatar that we don't have the cycles to do before mesh is released. If the community starts settling on a standard mesh and/or UV map after we release mesh, that would certainly be good incentive to push forward on this kind of project sooner, to help solidify the standard.

When we release the new asset format we're also working on revising the upload pipeline so that all of the mesh "pieces" you're uploading get sent up at the same time. It should definitely be possible to upload a bunch of pieces at the same time. The cap on vertices is on a per-mesh-asset basis. As the upload pipeline can generate multiple assets, you just need to worry about the complexity of each piece for this limitation. The advantage of the new pipeline is that the upload should be atomic - either the entire thing will succeed or you won't be charged.

As mentioned in the last usergroup, the weekly usergroup meetings don't have the right collection of lindens to discuss IP protections with. Its something we're very concerned about however, so I'd like to gather the feedback and concerns here so that they can be passed on to the correct people. Thanks!    -Nyx

Apologies for the confusion, but Monday is a US holiday (Memorial day). Next meeting will take place on the following Monday, June 6th at noon PDT.

Hrm, sorry about that - I edited the post with the correct link.

one bit alpha (alpha masking, as opposed to alpha blending) is a feature we'd like to enable in the future, but not for the initial release of mesh. As it involves adding additional parameters to an object's definition, I'd anticipate it to more likely be related to a materials project than the mesh project. This thread has drifted far from its original intent - closing for now. Please open separate threads for separate topics so its easier for everyone to find the information they're looking for. Thanks! -Nyx

as mentioned in the usergroup this week, we respect instance flags in uploaded collada files, but the resulting instances will be able to scaled / modified / limited independently from each other. Using the same model multiple times in your build will save downloading / loading times.

One project at a time. We're not going to hold off a mesh release until we can update the in-world avatar, so we're focusing on getting mesh out the door first. Future work to extend or replace the standard avatar model / rig / uv-map / etc would be just that...for the future.

As Arton stated, every LOD for your mesh needs to have the same number of material groups, so that we can apply the same "face" properties to every LOD.

Here is the agenda and notes from this weeks meeting: https://wiki.secondlife.com/wiki/Mesh/Archive/2011-05-23   Thanks to everyone who participated.   Next User Group is: Monday June 6, Noon Pacific Time. No user group next week due to a US holiday (Memorial Day) For information, or to add agenda items for next weeks meeting: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import/Scripting_User_Group 

Received! This appears to be https://jira.secondlife.com/browse/STORM-1260 which is believed to be fixed in the latest viewer-development. I'll make sure we do another pull from viewer-development to pick up the fix. -Nyx 

please post a jira with a log of the viewer that crashes, or email the log to me. There are a couple crash on startup bugs we've been hunting and I'd like to confirm that we're working on it already. Thanks! -Nyx

I haven't had the time to read through every post, but I've been keeping track of some of the ongoing concerns. I'll try to answer a couple of them here: 1) Meshes are no more difficult to render on a per-triangle basis than normal prims or sculpts. I've done some basic performance testing, and given avatars of roughly equal geometry (by triangle count), there is no noticable performance difference. There is a slight performance hit with rigged meshes but it fell within a couple of percent. 2) Meshes should be able to be significantly more expressive on a per-triangle basis than previously available content (prims and sculpts). The equivalent in geometry of the fully detailed mesh avatar I was using was 5 prims. Even the most efficient avatars I've seen use significantly more than 5 prims. 3) Making sure that meshes don't cause performance concerns is mainly a function of making sure that our algorithms for how many "prims" a mesh is equivalent to is correctly tuned. These functions are not finalized yet, and we plan on working with a lot of test content to try to get these numbers right, to get the right balance between offering incentive to use mesh and ensuring that we're not increasing the geometric complexity of the world. 4) Doubling the number of vertices in a sculpt would not only increase this geometric count (which we're trying to not do with mesh), but would not provide anywhere near the power and control that allowing mesh import would allow. In addition, sculpts have fixed (poor) LOD management and loading behavior. We've made great progress on the mesh import project and believe that it should allow users to create much more expressive and much more efficient content than extending the functionality of sculpties. Thanks for the feature suggestion! We're going to focus on mesh import for now though.

Here is the agenda and notes from this weeks meeting: https://wiki.secondlife.com/wiki/Mesh/Archive/2011-05-16   Thanks to everyone who participated.   Next User Group is: Monday May 23, Noon Pacific Time. For information, or to add agenda items for next weeks meeting: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import/Scripting_User_Group 

Apologies for the confusion! Its important for physics, yes, but our algorithms under the hood should be ordering triangles in this manner for rendering anyways. You guys should not have to worry or stress about the winding of your meshes.

Edited post to correct the date - thanks for the catch Drongle!

Here is the agenda and notes from this weeks meeting:  https://wiki.secondlife.com/wiki/Mesh/Archive/2011-05-09   Thanks to everyone who participated. Please note that we have a new time for the meeting starting next week!   Next User Group is: Monday May 16, at Noon Pacific time. One hour later than before! This will be our meeting time for the forseeable future. For information, or to add agenda items for next weeks meeting: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import/Scripting_User_Group

In a word: no. Avatar physics will not affect avatar attachments, which rigged avatar meshes are. Avatar physics utilizes some morph parameters that exist in the standard SL mesh that aren't exposed to imported rigged meshes, and therefore won't have an effect on them. Good question though!

Here is the agenda and notes from this weeks meeting:  https://wiki.secondlife.com/wiki/Mesh/Archive/2011-05-02   Thanks to everyone who participated.   Next User Group is: Monday May 09, 11AM Pacific Time. (* We may have to change the usergroup time, but it will still be on Monday) For information, or to add agenda items for next weeks meeting: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import/Scripting_User_Group

Its a three color scale, though I'm not convinced the blending between the three colors is the smoothest. Its a pretty rough demo at the moment I had set the max scale to 3000 for the video to demonstrate the tool - the default scale recomputes each frame to scale across the range of visible items, so you can see what is the most expensive object in your view. As for the new algorithm, I'll be documenting it (and how I reached the numbers) once I have a few more of the factors figured out. I've been doing performance testing to ensure that each factor is scaled appropriately. Some of the results have surprised me a bit, but make more sense when I think about it, and I've made sure to get repeat tests for things that seem....unlikely. More details later!

As I mentioned in the usergroup meeting today, I hacked together a bit of a demo on visualizing the render complexity of various objects in a given scene. Check out a demo of it here: http://www.youtube.com/watch?v=8aIelrNTnFU For reference, Blue = good render complexity, Green = fair, Red = poor. For those of you who like specific numbers, the colors scale from 0 (blue) to 1500 (green) to 3000 (red). Anything over 3000 is colored as red. Note that this is using the new (unfinished and unpublished) render complexity algorithm, which is different than what you see in the current mesh viewer, so your objects will be weighted a bit differently. If you want to check out the effect, you can grab a test viewer here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/nyx-viewer-mesh/rev/225046/index.html A few caveats: 1) This is an untested build on an unstable branch. I make no guarantees! 2) The new render cost algorithm is not currently finished/correct. The numbers *will* change in the future. Particularly in the following areas:  - Meshes (weighted and unweighted)  - prims with animated textures  - prims with media textures  - prims with fullbright faces  - possibly some other areas I'm forgetting at the moment   3) This feature has seen no formal QA, its a test I put together quickly. I appreciate constructive feedback, but know that it is unlikely to be perfect at this point.   In order to see the new display, turn it on by going to Develop > Render Metadata > Render Complexity. Note that the specific scores of each linkset are brough up in addition to the colored highlight. You can control the effect with the following debug options: Render ComplexityColorMax - color of the most expensive objects (default: red) RenderComplexityColorMin - color of the least expensive objects (default:blue) RenderComplexityColorMid - color of a mid-range complex object (default: green) RenderComplexityStaticMax - set a static value for what render complexity equates to "max". Any objects at or over this value will have a highlight of the color RenderComplexityColorMax. If this value is -1, the scale will be recalculated each frame to color the objects based on the current view. (default: -1) RenderComplexityThreshold: objects less than this threshold will not be colored. This does not have any impact on the color scale's minimum.   Let me know if there are any questions, comments, or requests!    -Nyx