|
|
|
Paviq - I think the problem right now is that we have a lot of content creators that want to bring their designs or creations into Second Life or other VWs. The problem is that these content creators are scattered across many different domains and applications.
You are correct that SL is very limited in terms of geometry. So some discussion is needed on how to improve this. Sculpties are step in the right direction but don't go far enough for many content creators. So, ultimately, some technical disucssion is needed on this. However, I think the first step is to demonstrate the need and raise the visiblity of the issue. So getting non-technical "content creators" to vote on the general issue of input/output rather than the specific issues like obj or jt seems like a good idea. There is not enough visibility of this issue with everyone pushing there individual agendas. Theory - correct me if you had something else in mind. Theory,
The University of Cincinnati did some work on importing JT format: http://www.slideshare.net/rhemant/uc-jtlsl-translator/ Also, in terms of Mechanical CAD, you probably want to list the key applications: AutoCAD (you have this) (there are several others smaller players too. Don't mean to exclude anyone.) 3D formats often used to exchange data between these systems include: .JT, Parasolid (.X_T), .STEP, .IGES (There are a few more too) Note: I work for Siemens which owns some of this but my views represent my own. I'm also trying to stay objective in this (not too hard because I think all CAD content creators have similar needs). Mark I realize this isn't supposed to be a technical discussion, but there is a very big technical difference between importing and exporting models from other applications.
Adding a general purpose importing capability would be huge project for LL. The different formats is not the major obstacle; it's the fact that for lag reasons, building in SL is restricted to a handful of basic shapes that can only be modified with another handful of pre-determined variations. (Sculpties are more flexible, but far from being general purpose.) Trying to make a satisfactory approximation of an arbitrary 3D model with the existing prims would require way too many prims. So importing 3rd party models really implies adding new building constructs and would require augmenting large parts of SL. On the other hand, exporting SL models in a standard format that could be imported into most any 3D modeling tool would be a small project for LL; they would just have to be convinced there is sufficient demand. To be effective, I suggest we focus the lobbying effort on exporting. I think there's two seperate things here - export and import, which present different problems.
Export of prim builds is indeed fairly trivial (though not without it's problems). The prim format is not so optimal for other systems which don't have prims. Even so people are already doing this, using opengl driver patches that rip the geometry out of whatever you're looking at in sl and allow you to import it into 3d programs. Clever folk are even taking 3d rips of their avatars that way. The problem of export I think predominantly a community one. Whenever an asset leaves the sl bubble, members of the community scream long and hard about copybot and LL acting as big brother to protect our assets. LL needs to know that we encourage the free flow of assets in and out of sl (with reasonable checks that you actually own/created it) and that those who scream loudest about avoiding such functionality represent a paranoid minority. (Well they do have a point, but import/export is far too useful to throw away in the interest of protecting against the possibility of misuse if it's responsibly implemented.) Import is a different matter. The non LL branches of the client and server have shown that using arbitrary meshes in sl is just a few simple patches away - the capability is there. The problem is LOD. For the uninitiated LOD stands for "Level of Detail" and is a trick that reduces the graphics lag you see in sl. Prims and sculpties are designed in such a way that, (if you turn your mesh_detail>objects slider down in graphics preferences... or simply move far away,) they can reduce their geometrical complexity so that your computer doesn't have to work so hard to render them. Sculpties were a brilliant solution to allowing this by default - their square absolutely regular mesh shape means that SL can simply throw out all the odd points, then the odd points of what's left, etc. Lag is thus reduced. With arbitrary meshes though there is no obvious way of reducing the level of detail at a distance. For this to work either LL needs to invent a very clever way of reducing the mesh geometry, or they need to give us the tools to do this ourselves. If either one of these isn't available lag will result - and as we know, if we leave it up to the community to practice self discipline for it to work, then lag is the likely outcome None of the virtual worlds I am aware of has completely solved the LOD issue, and either relies on only allowing professional developers to produce models, or hopes against hope they can make it work without growing to the size of sl, or anticipates that everyone using their grid will have an overspecced gamer gruntbox which can take it. So ignoring the problem is only asking for trouble later. I am assured though that the clever people at LL are putting a lot of thought into the issue to try and figure out a clever way of doing it. The problem of deciding what geometry to throw away is a difficult one. The lindies either have to choose for us (which might cause noses to disapear and edges to wiggle) or find a way of allowing us to choose for ourselves. This is something that could possibly be done on/before upload by allowing us to "crease" our models to say which bits should remain solid, or one of the native 3d app mesh tools (such as edge loops) could maybe be used to assist in suggesting which geometry to save. The problem is not insurmountable, but certainly difficult to solve in a way that is both elegant and usable. Sculpties for example are elegant, but not so usable Technical post I know, but I thought it worth clarifying some of the problems (in i hope a not too technical way.) Arbitrary meshes (imported and exported) have been demonstrated on SL technology based grids so on the surface it would seem simple to implement, but in reality that's not the only problem LL needs to solve to ensure the grid remains stable and usable I guess i'm not asking for the Kitchen Sink right away.
Just a simple, user-friendly way to create a simple Box, Cylinder, Prism, Sphere, Torus, or Tube in a 3rd party program (within SL's prim limits:size, number, etc.) and import that object in Second Life. ... and in turn modify that Box, Cylinder, Prism, Sphere, Torus, or Tube and export it to another format. [insert popular file format here... ex: Collada (.dae)???] I don't need an wildly organic 'kitchen sink' quite yet... just a simple plain 'boxy' one will suffice. ... and since i want others to modify my Kitchen Sink outside SL if they so choose... Why can't i check something like.. 'Export out of SL' ...under 'Next owner can:'... right next to the other options... 'Modify' Wouldn't that protect owners and creators from unbridled plagiarism? I think this issue has been poorly filed, it makes no case for implementation and is bogged down in discussion of file formats (A technical issue!). It is also too heavily linked to export which is a seperate unrelated issue, exporting primitives to a mesh has little relevance to importing a mesh.
Eata, I see your point. One of the problems is that the geometry issue quickly fractures into a bunch of special needs which are all small and never get any visiblity.
I was hoping this JIRA would allow some comunity building around the issues. I could certainly make a case for implementing what my domain or industry needs but I would expect it to overlap with other peoples needs (and have more weight becuase of this). If we view "3D content creators' as the owner of customer, I think the primary desire is for import, not export. As has been pointed out, export would probably be considered a bad thing in some cases.
For import, the desire is to use either existing 3D creaton tools or new tools that might be created. Today, a number of content creators are using Maya or Blender or some home grown scultie tools. This has been very helpful but is still a difficult path. We need to get to a point where content creators can use there own tools without any hardship in getting their creation into Second Life. Hi,
not sure if this fits in this discussion as it is not really related to the 3d shape of the object, but I would like to know if there is any way to build a simple SL object (where for simple I mean simple shape, with a runnable script) outside of SL and how to import it in SL afterwards. If so, which is the object's format? thxlot Anyone interested in this issue might want to participate in Qarl's survey on the importance of importing new content type vs improving the in-world building tools. See http://jira.secondlife.com/browse/MISC-1494
Thanks Omei. Very closely related issue!
Are you aware that Hexagon 2.5 allows you to make prim based designs. While these aren't exportable (sculpties are; its the purpose of the addin). Its save able in other formats.
Since this is specifically nontech, I'll mention that in particular, CAD, SketchUp, and Revit plugins/compatibility would be awfully handy for the architects that would like to collaborate and show in Second Life. I'm VERY nontech.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I suggest that anyone who is using a pro 3d application listed above (apart perhaps for sketchup) is already either "technical" or needs to become so to discuss the best way to deal with import and export of assets. The current implementation of sculpts in sl requires more knowledge and discipline than the use of arbitrary meshes one can produce in any 3d package (due to the severe constraints on geometry, complexity, and issues of LOD.
The architecture of sl 3d creation would need to be extended I think to allow arbitrary mesh objects before such a workflow would make sense. But that's just my two cents, and this jira has my vote, because it's worth discussing how we can improve interoperability, especially of 3d assets.