DanielRavenNest Noe

I started learning 18 months ago, and there is a bit to learn, but fortunately there is plenty of nice people and lots of online information about computer graphics and 3D modeling. Those are the proper terms outside SL. Technically a "mesh" is a set of triangles which share common edges. A 3D model consists of one or more meshes in a single file, along with other data besides the arrangement of triangles. Triangles are used universally in 3D graphics because they are the simplest shape which has a visible area. Type Ctrl-Shift-R in the SL viewer and you will see that the scene is actually made of triangles and always has been. Prims are just pre-made models with the ability to modify them directly in the viewer, with limits on how you can modify their geometry. You can stretch a box prim, but you cannot turn a 4 sided box into a 5 sided box. Model import will let us define custom geometry of almost any type, at the loss of in-world changes like twist and cut. That's not really a loss since you can do the twists and cuts before you import it.

2.7.0 Beta (230551) appears not to work - old meshes will not rez, reuploading the same items leaves them with no name at all in inventory, and looking like a small disk when rezzed. Edit: on Mesh Sandbox 28 with server Mesh Experimental 11.06.01.231687

Have you actually been on the beta grid? When you upload a mesh, you find out the prim equivalent. That number is still to be adjusted to a final formula, but we have more than zero information about how it will work. I estimate 50 prims based on other models I have imported, but if it turns out to be 25 or 100, it's still too much for a window. Now, its obvious you were wrong about there being stolen content on that site, though I'm sure you will not admit it. And you are wrong about most other things you have said about mesh, but I don't expect you to admit that either. Good luck with Evermotion filing a DMCA action. They are located in Poland, and Archive3D is from Uzbekistan, so they have no venue for a US law to apply: http://who.godaddy.com/whois.aspx?domain=archive3d.net&prog_id=GoDaddy Now, if that item is uploaded to Second Life, they *would* have the ability to file a DMCA action, because Linden Lab is in the USA. That will be a deterrent to wanton uploading of any models scraped off the Internet. Yes, it's not hard to find them and load them into SL, but it's also not hard for experienced 3D modelers to recognize where they came from and tell the original creators. Along with upload costs, that will limit somewhat how much stuff is ripped and brought into SL.

Hi Saru, I sent you a copy of my "Experimental Mesh Avatar" on the beta grid (Aditi) to play with. To answer your questions: (1) The default SL avatar has a body geometry (ie a mesh), and a UV map (the three skin textures you set up according to a template). The body geometry is attached to a set of "bones" which are used to animate the body. If you create a new mesh-based avatar or body parts, it will use the same bones to control movement, but you can make custom geometry and UV maps. The custom avatar is worn like a clothing item, and then you hide whatever parts of the default avatar you need to. Creating the geometry and UV template is done in some 3D program and imported. The actual skin textures are done in whatever image editor (Photoshop, GIMP, etc) you prefer. (2) No, only the underlying body shape changes that affect the bones will affect a worn mesh. Other appearance changes that only morph the default skin will not affect the worn mesh. (3) There are two kinds of mesh clothing, those which are set up to follow the bone animations (called "rigging"), and those that are not. The latter will act as any static prim object. You can wear them on some part of the body, but they will not deform when the avatar moves. Rigged clothing will follow the avatar's movements, for example a sleeve will follow the arm bones if you set it up that way. Whether it will fit a given avatar depends on the body settings for that avatar. Rigged clothes are indistinguishable from rigged avatar bodies as far as the SL software is concerned. They are made the same way, and only look like a body or clothing by how they are made. Because rigged clothes will only follow bone changes and not skin morphs, you would probably need to make several sizes to fit different avatar shapes. If you make both clothing and avatar mesh rigged the same way, they will both change the same amount by twiddling appearance settings, so they should keep their fit.

Well, the SL wiki pages on Mesh could use a lot of updating: http://wiki.secondlife.com/wiki/Mesh I have held off with updating the 3ds Max stuff (which is the program I know best) until the SL code reaches some stable condition, which will hopefully be soon.

Yes, they are stolen. For example this item: http://archive3d.net/?a=download&id=42542 Is a copy of Evermotion Archmodels vol 4, window model 108. It has the same geometry exactly. And at 14,000 triangles it's way to complex for an SL window - who would want to pay 50 prims upload cost or parcel prim count?

First of all, the proper name is "3D models", not meshies (yuk). 3D models are easier to make than sculpts, so this is a step to letting more people build stuff. @ Vivienne - I don't know why you keep linking to a site full of stolen 3D models, but in any case those are not directly useful for SL. They generally have way too high a polygon count, since they are made for static renders, and not real-time games, do not have proper Levels of Detail or physics proxies, and sometimes too many UV maps. Often the models are for exterior views only, so as a building, if you walked inside it would be invisible. So if someone wanted to steal those models and use them in SL, they end up having to rework them a lot. Either that, or end up using your whole parcel prim allowance for one couch.

http://community.secondlife.com/t5/Featured-News/Mesh-Coming-to-Second-Life-This-Summer/ba-p/902061

Poenald Palen wrote: SL is moving toward becoming a leader in mechinima, IMHO. The camera control, the lighting and now features like DOF are all very much stuff that is going to make much more artistic stuff. Sorry, but that made me smile. If you want to see what a real leader in cinematics can do, take a look at the "Track View" pages from the Cryengine 3 manual: http://www.mediafire.com/?pkbudm63bai4mu9

There is a comprehensive comparison at http://wiki.cgsociety.org/index.php/Comparison_of_3d_tools Not listed there, and free, is Google Sketchup http://sketchup.google.com/ which is fairly easy to learn. Partly it will depend on personal preference, and partly on what you want to do with the result. If it is just to make photographs, most any software will do. If you want to do photorealistic renderings, animations, or export to some other program, your choices will be more limited.

Note that the cost it states in the upload window does not match the cost when you place it on the ground and look in the edit window. That said, 340 is way high. What kind of object is it, and how many triangles were listed on the upload window?"Levels of Detail" or LODs, and physics proxy do matter, but it sounds like you have way too much detail in the geometry.

I have gotten a model (250 triangle plant) made in Max 2012 to upload and use in the Aditi mesh regions, so it does work. The thing most people do not understand is Collada .dae files are not a format standard like jpeg is for images. It is an XML scheme for how you transfer 3D model data between programs. It can handle a lot of data types, but any given program may or may not implement them all, or in the same order. And how you set up the model in Max matters too, if you don't do it right it can fail to upload to SL or crash the viewer. Once the SL internal format is stable, we can document exactly what is needed for each 3D program as far as setup, but we are not quite at that point yet.

Not necessarily. Procedurally generated scenes are a powerful tool, but they have several drawbacks. One is that they require more processing at the user's machine to build the material or geometry out of a procedural formula. Another is applying a static texture is simple to understand. In a world with user content creation, using complex node-based generators like Allegorithmic's product may be too hard for most people. Here are two scenes I created using two different editors that use "procedural" methods, to show what can be done: http://lh6.googleusercontent.com/-KUtb9rlDl2s/TeEBUkBOPcI/AAAAAAAACiA/tUQID-c_9xY/s1440/3%252520hills.jpg The first only has about 6 types of object in the whole scene: fractally generated terrain shape, fractally generated terrain texture, a tree, and three kinds of grass. The grass is randomly scattered by "painting", so each tuft only needs a location, but all the tufts are copies of one of the three models. The trees I placed by hand to make a nice photo. http://lh4.googleusercontent.com/-jqfcK4qWpEM/TapoP3mOhSI/AAAAAAAACfM/CCtJaSbK1t4/s1440/TerrainExample.JPG The second has 3 objects: a tree, a bush, and a grass, and the settings on the right allow applying them to the whole of a terrain area like the grass or sand, but with parameters for altitude, slope, and density to control where and how many get used. The distribution on the map does not exist in saved form at all. The plants are instanced as needed within your view distance as you move around. So these examples show you can get cool results without using a lot of items, but the methods are not as easy to understand as applying textures to a prim, and they require a fairly good graphics card to implement (at least for these examples).

Yes, I have done it. You need to use the same exact bone set as the default avatar (scale, position, and bone names and links). There are examples of the default set floating around for different 3D programs.

Ignore my comment in the other thread about polygon count, I didn't realize you had experience doing game mods. There will be a transition period as Mesh-enabled viewers ramp up in use, but I think once people start seeing pictures of what they are missing, a lot will switch over. The approach I am taking is to try different types of models to learn the SL workflow, but I am not mass producing stuff yet because the software isn't final. In fact, a change to the asset format (internal to SL) is due any time now, so anything already uploaded will need to loaded again. Once a release date is announced and we know the software is stable, that's when I plan to start producing in earnest.

3ds Max works fine if you already know it. I have used 2010 and now just started using 2012. For SL: - Units should be metric. - Final model should be editable poly, with one multi/sub-object material, no more than 8 material IDs. - If you have more than one object in the scene, it will end up as separate objects in SL. - You can apply UV maps to the object - Use recent FBX plugin, 2011 or 2012, and export with Autodesk Collada, with Z-up. - For now, to try uploads, you need to be on a Mesh-enabled region on the beta grid (Aditi), and using a viewer with the mesh features working. - Textures are uploaded separate and applied to the object in SL - If you have done visualization, but not game/virtual world models, the big difference is the latter is real-time. So you can't use millions of polygons and take 20 minutes to render a frame. Models should have as low a ploygon count as possible.

There is a maximum complexity limit of 64K. I am not sure if that is per object or per upload. There is also a maximum size limit of 64m, also not sure if that is per object or per upload. It should be easy enough to test, though. If you have more than one object in the upload, they do arrive in the correct positions to each other.

You may not be the right people to discuss the legal issues, but you are more informed than the corporate counsel on the technical issues. * One way items have gotten stolen in the past is using a viewer that allows export of an object linkset and associated textures, and then re-importing it as their own. What we upload for 3D models is a Collada .dae format file, which I understand is *not* the format they are delivered to the viewer in. That may help reduce one kind of illicit copying, but it does not help if someone applies the mesh asset UUID when re-importing. * An entirely different issue is illicit importing of existing 3D models from outside SL. On a mechanical level I don't know of any way to prevent it, since the Second Life system (client, server, and asset databases) cannot check against every 3D model in existence. Upload cost for high polygon models will prevent wanton import of some commercial ones, but I don't see anything else limiting them.

One guideline is if it's less than a pixel off on a large monitor, you don't need that detail. So assume the table is 1/3 the screen height at normal view distance. On a 1920x1200 monitor that will be 400 pixels tall. On a corner, you can do a square edge, a chamfer, or a circular arc. The more sides in the circular arc, the closer it gets to a perfect circle. If the deviation from perfect at the midpoint of a side is less than a pixel, people viewing it will not see the difference, especially if you use smoothing groups properly. Same general rule applies to texture sizes. If the texture pixels as displayed on the object are under 1 pixel on the monitor, the texture is detailed enough. The only question is what you consider an appropriate viewing distance, which will vary somewhat by type of object. At the closest, there is a camera clip distance of around 0.5m. Anything closer isn't rendered, so that sets a minimum feature size you can see of around 0.5mm.

What you are talking about is in the general category of "procedural generation". It is already being used in some 3D graphics, and is likely to increase because it is so efficient. Some examples: * Cryengine 2 and 3 vegetation -- You define one geometry, like a tuft of grass, and a set of parameters for spacing, random size variations, etc. Then the graphics engine places as many in view as needed according to the parameters. The server does not need to track where each one is, since they are generated locally on your PC. * E-on Software "Vue" landscapes -- Terrain and plant detail are generated by a fractal formula as needed. * Allegorithmic "Substance" materials -- This generates textures and other bitmaps from a set of parameters. The common feature is reduced storage and data transfer needed, at the expense of some more calculation when used. Since computers and graphics cards only get faster with time, this gets easier to do. What is preventing the efficient use of mesh instancing is the lower bound of exactly 1.00 prims and no less for any object. If prim accounting had more decimal places, we could do things like a fence out of repetitive simple objects and not get overcharged for the complexity.

I made some terrain just yesterday :matte-motes-smile: http://lh4.googleusercontent.com/_N3W3ksl-Xiw/TdnHPLTmFlI/AAAAAAAAChM/QFJ0MAuH5Uo/s1600/Hill.JPG About 6000 triangles with a physics proxy, 11 prims by the current (unfinished) cost. 64x64m. I only used 1 texture for it, but I could have used 4 textures and mixed them by UV mapping or used seamless repeats if I wanted. The actual texture is "slope matched". Flat parts are grass and steep parts are bare. My suggestion is ignore the default terrain and just make our own. We would have more flexibility in textures, and be able to make overhangs and holes, and height details smaller than 4m. In this model the flat areas have larger triangles and the bumpy areas have more detail. Since the new prim size limit will be 64m, you can cover a sim with 16 terrain tiles and use about 1% of the total prim allowance at the detail level I used. (Hi Naiman, I'm sure you know most of this from seeing your work on other worlds, but my comments are more for other people who don't know as much about 3D models and what the possibilities are)

I made an experimental Mesh avatar: https://marketplace.secondlife.com/p/Experimental-Mesh-Avatar-Female-Boxed/2059187 I did it in 3ds Max, but the process should be similar in Blender. You need to import a "bone structure" that matches the one that SL avatars use. Then you weight the vertexes (corners) of your model to whichever bones they need to move with. That gets exported to a Collada file, then imported to SL. As far as I know Blender 2.57 does not export correctly (it's still in beta and not done). When imported to SL, you just wear it anywhere on your avatar, and it will follow your movements. I did a 100% transparent alpha layer to hide the default avatar. The tricky part is getting the weights right so it moves properly. Look in past threads here for pre-made bone setups, some people have already taken the SL original avatar and copied it for use in other 3D programs.

Viewer Development 2.7.0 build 230331 appears to have fixed the problems. It works on both the Main grid and Aditi mesh enabled regions, where it shows meshes and allows uploads. You can download from: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/rev/230331/index.html Latest "Viewer Development build can be gotten from: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/latest.html (There is no guarantee that any particular latest build will work, sometimes they have bugs. That's what those daily builds are for - testing and finding bugs)

For those who are not programmers or mind readers, the crash log is found at [your user directory]\AppData\Roaming\SecondLife\logs\SecondLifeCrashReport.log on Windows machines. It is normally a hidden folder, so you may have to unhide the hidden folders first to find it. I assume, because I could not find it posted anywhere, that the email is nyx (at) lindenlab (dot) com. I sent you a crash log on the latest version (build 230378). Build 228967 is the last one I have that works.

All the 2.6.9 viewers I have tried the last few days have had problems. Have to wait till they fix the bugs I guess. Last one that works for me is 2.6.8: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-development/rev/228967/index.html