|
History
| Log In
|
|
|
|
|
|
I posted the source code for the basic OBJ importer. This first patch works fine with 64x63 sphere meshes made with Wings3D, or other modelers that can create such meshes.
I'll have to update it again to smooth out the polar faces, but it is an example for now. i think there's a danger in creating this sort of importer:
it REQUIRES the input mesh to be of a very specific shape. it will fail for 99.99% of arbitrary obj files... this will cause even MORE confusion for novice sculptie creators, who try to download a mesh from turbosquid or whatnot, and expect to be able to import it. if you're able to create the very specific obj file required - that means you've created it inside Wings3D or whatnot - where you've already got an import method. The source code was just a first pass to add the ability, as like a proof of concept it can be done.
It can be easily changes to allow more arbitrary obj files, and it can have the option to take the mesh point as-is or to interpolate them into a secondary mesh that will better fit the import. It is obviously more fair to the general users to allow a import of a more popular format than to require methods to go through several programs to get it imported. Maya just doesn't appear to be the popular choice of packages used. I can easily compare the rationale to a stock market, where only a few people have the privilege to trade while everybody still pays the premium. You Qarl, you don't have to waste your time on this. I can do it. =)
Oh ya, I use Amorphium, which is $80 at this time. I can export the require OBJ files directly from Amorphium and right into Second Life with no other program needed. Wings3D is still an awesome tool to keep under the hood.
Here is a download section for the binary:
http://sourceforge.net/project/showfiles.php?group_id=191214&package_id=235614&release_id=516188 Dzonatas -- it is *extremely* cool that you are working on this. Qarl is going to work on getting you some clear guidelines for what kind of a patch would be acceptable to have in the main viewer code.
There are several reasons that we feel the need for extra diligence on this work: 1) This is a new feature, and it needs to go through more extensive QA, including possibly a beta release 2) If the importer fails on a substantial percentage of .obj files, we at LL will get the contacts and have to support 3) We need documentation (knowledge base, internal viewer doco) which clearly describes when this importer can and cannot be used. Qarl should weigh in on the topic this week. Periapse, us programmers are artists, too. =)
and another thing why do we still have these retarded aves
you have given us wind light, sculpites, flexi ,lighted prims and soon to be voice yet we still have these same undersized model aves with skin and clothes thats 2 sided why am i making 2 sided skins and clothes when i should be making one sided sleeve textures like i do for all of my poser models? for crying out loud your on a havoc engin not a dang old doom 1.1 and dont give me alot of junk about meshes and stuff . every online game for the past 5 years has done this why are we still behind. or do i allready know the answer all of the designers would have to learn this method vs the one they know. That might put folks like me ahead of the ball game as current designers have to learn this method just like i have to learn how to do sculpties. so lets even the playing filed and implemnet new aves and junk these old ones and you go Dzonatas lead follow or get out of the way ;p lucian hey Dzonatas. here's my concern:
i think it's going to be VERY difficult to handle arbitrary OBJ files in a way that'll make the residents happy. (lord knows, it's hard to make the residents happy. :) right now i'm imagining that some shapes will lend themselves to a shrinkwrapping technique, while others will be better with some kind of "simulated pelting" (with skins and springs to stretch it out) and yet others will work best with a hand-tweaked UV space pre-export... etc, etc... but as Lucian so eloquently points out - perhaps you have an idea i haven't thought of. if so, let's take this to email... i'd personally LOVE IT if you gave us a patch to do this work. :) K. Periapse is right - i should lay down some specific criteria for acceptance of an OBJ importer. i think this covers my only concern:
the importer should be able to import (without serious error) at least 90% of the shapes found on turbosquid.com. so yeah, that criteria is a little loose - but it gets us in the right direction. Download a Viewer with this feature: http://sourceforge.net/project/showfiles.php?group_id=191214&package_id=235614
Patch: vwr-1110.1.18.0.6.os.1.patch.txt
Applied to Open Source Viewer, 1.18.0.6.OS.1: http://sourceforge.net/project/showfiles.php?group_id=191214 Upload is enabled in version 1.18.0.6.OS.1; however, I suggest to only test upload on the beta grid (ADITI). Select ADITI grid when you log-in.
We can't accept this patch into the mainline viewer without a signed contribution agreement on file. Could you send that in?
hey Dzonatas - how's life?
a few lindens keep poking me and asking about this patch, whether we should apply it or not. i think you agree, the patch only works for very specific meshes right now (64x64 vertex meshes, laid in a grid) and so does NOT meet the 90% criteria mentioned above. yes? no? Of interesting note: A person, who shall remain nameless, said this about this subject when contacted about it:
"No way... and give up my advantage? I do perfect sculpts already... No need to make it easier for my competitors :) I only supported the importing of .OBJ files before I broke the problem of sculpting. Sculpties, as they are now, demand much knowledge. Importing is easy... if it's possible, then the market will explode. Sculpting as it is now... is next to impossible for most people... but not to me." I'd probably guess who that nameless person is but I have a contract that doesn't let me speak about "insider" information. (Notice how LL's copyright is on the patch.)
This work could have been done by now, but I've been kinda "pushed to the street." Let me point out this: http://lindenlab.com/employment/tao "Work together! The problems we face in creating Second Life are usually larger than one person can solve, and solving them together is one of the great strengths we have as a company. We will succeed only if we collaborate with each other extensively and well. This means helping others reach their goals, asking for help and input often, and being easy to work with. Create teams as necessary to solve specific problems, and support your teammates. Remember that being open and honest is essential, but is only the threshold requirement - great collaborative work requires intuitive compassion and support." and "No Politics! Never act to advance your own interests or someone else's interests at the expense of the interests of the company. This is the one principle, outside of violations of law, for which violation will likely result in immediate termination. Might Makes Right Just kidding - wanted to make sure you're still paying attention. Lots of things could be said here: Have a sense of humor. Have a sense of humility. Have fun. Call out inconsistency in principles when you see it. Don't let a staid form and function become routine and boilerplate. Which leads to our last principle..." What's interesting is that a lot of my other patches have been included in the official release, but this one is quoted as "danger in creating this sort of importer". Rob also noted something above on Aug 2nd, but my others patches have been included. Strange they want the contribution agreement for continued work on this patch when they know I have a contract that allowed the other patches to get into release. But you know, the original patch here is just an "example" as stated in my 2nd comment. Well, the comment was not made by a Linden staff person, just a random artist.. We have to put pressure on the Lindens to show practical and possible ways to improve Second Life... that's what JIRA is for.
The comment I received from this unnamed person is similar to what a (also unnamed) LSL programmer told me recently: he preferred that combat systems on second life remain unrealistic, awkward, and broken, because he makes lots of money off of creating HUD-based weapons systems that are used to "instantly kill" other avatars and use various complex hacker-like tricks for SL "combat". The point is, the harder it is for creative people on SL to achieve things without too much trouble (a situation that would benefit everyone) the more it encourages elitism and market-monopoly by a small number of people. Now, if we think the so-called "free market "is meant to only benefit a few people, I guess this is fine. But if we believe it exists to benefit everyone, then we better start correcting this situation now.. Anyway, since the Lindens what you to sign a new contract that you cannot accept, rather than their regular contract, does this mean that importing .OBJ files just isn't going to happen on SL now, Dzonatas? If that is the case, I hope Qarl Linden will consider writing an .)BJ to Sculpt Map importer from scratch, so this will still be possible... otherwise, this issue won't be going anywhere. :( LL's contract, as a Consultant, works fine.
Last time I tried to explain why the public contribution agreement (as being signed in sent in) doesn't work for all cases, I got an e-mail from LL that didn't answer to the explanation, but pretty much told me to shut-up about it. The concern you mention above does actually spread more than noted. You say it wasn't from a Linden, but that doesn't really matter for the main point. It's like a scale with one side having "competition" and the other side having "working together". Sometimes the competitive motives prevent being able to work together. In order to advance the technology at hand, one would have to give up being so competition, as monopolizing, the potential technology. The real question is, why do importers have to go through the sculpt map process as Qarl demands above in order to be 100% qualified? This example shows the potential to import meshes from other formats. It's kinda odd requirement. It's the right direction. We can say, however, that not even SL, as it exists right now, would be qualified under such requirements. Should we just junk the whole sculpt map process until it is 90% perfect? Really, his "90%" requirement is entirely a different issue than just a basic OBJ importer. I can't deny that such requirement hijacks this issue and every other kind of importer. Dzonatas; it's a quality assurance issue, there's no point in them adding a feature if it's going to fail most of the time. However, if it is generating a sculpt map while importing, then surely it could at least show the sculpty preview? If it does that then I would think that that would be enough.
If you do any more to the obj importer then you could end up causing it to try and force objects to become sculpt maps which simply can't be done with them, or worse, cause false adjustments that ruin perfectly valid objects. If it works for a clearly documented set of requirements (ie the obj can't fold in on itself or something) and shows a preview of how a given obj will, then it should be acceptable. But what LL are interested in here is what the whole point of the open-source initiative is; they want stuff done for them, but they can't accept stuff they wouldn't put in themselves due to being too restricted or such. A bit hypocritical considering some of the bug-fixes that have changed behaviours, my peeve being avatars on phantom objects no longer being phantom, changed a while back but very annoying. There is not a lot of details I can give right now, but you are right about the QA part. It doesn't mean the importer will fail at all, but it means that it might not be best for the current design of the viewer.
I'll leave this issue open for now since there is still inertia on design of the best way to implement these kinds of importers. =) As I explained in VWR-2527, it is best that even if a 3D object file format supports features that are impossible to render in Second Life, that when the user wishes to import the file, a list of several procedures based on differing mathematical and computational algorithms and computer science concepts*be offered, and the results of each type of processing be shown. The user can then pick the best one that suits them. for that specific object to be imported.
Hey guys,
I tried downloading the viewer and working with it.. but for some misterious reason, i am not able to login.. the login works fine on a normal viewer... would be great if you could help me with this... Thanks, Raja @Miller, I think that is a good idea. How it is actually implemented is vary, but you are right the option should be available.
--- @all: Since this has received more publicity (so I don't have to pinch my lips so hard)... Has anybody taken a look at the COLLADA format? http://en.wikipedia.org/wiki/COLLADA It gives lots of options on storage/exchange formats all combined into one standard. =) (There is more about it than just the format itself) Here is a new design that has inertia: https://jira.secondlife.com/browse/MISC-830
And, it meets or beats the 90% requirement that Qarl stated early on in this issue! =) This page answers my question if LL is working to enable the import of OBJ or ASE (real 3D Objects) into SL. It looks like Dzonatas found a solution for this but from what I read nothing is happening because of some policy related issues and uncertainty of the quality of his patch.
I myself am also looking forward to see real 3D objects instead of these "low quality" sculpted prims. LL seems also eager to implement this in the system and it would improve the quality of items in SL in a drastic way. I hope this topic is on the heigh priority list and it's fair to say this is a must for SL. Windlight is nice and a good step in the right direction. The import of real 3D objects and Poser made avatars will have a very positive impact on SL so I hope to see movement on this subject soon. LL I'm sure you have to knowledge and resources to do this, virtual worlds have 3D objects, real ones not just primitives, put it in beta for 2 years but I think it's more than time for the introduction of real 3D object item import into SL. And after that better programming languages like Lua. Best regards, Count Burks Sadly, no contributor agreement on file for accepting the patch, and this needs a fair amount more work given the above feedback. If anyone wishes to re-implement with the above in mind, we'd consider re-opening!
well, such an import facility would be fine. As long as we do square houses, we don't really need it, but anything else would take a great profit of any ability to create other primitives than the small number provided (cube, sphere, cone, etc). As soon as my first building I needed better prims (a large dome with a curved opening, I had to make do with a sphere with a triangular cut).
Sculpties are interesting, but they have some drawback, like slow download, and the rectangular mesh is not necessarily appropriate. For instance a sphere will have overstretched faces near the equator, and a crumpled pole. I also tried "Prim Importer", but it seems not to work. Indeed the documentation is very poor, and I am even not sure of the file format it works with. Qarl Linden, it would be interesting to know what are the kind oj object files which would not work in SL. For instance do these shapes need to be "closed" shapes? Or can we remove, for instance, the faces under a house? It is a common tip in 3D modeling not to define faces which are not to be seen in any case, but this makes some renderers or modelers to fail. We still have to keep in mind that with our very own custom true 3D geometry, we would be able to import "primitives" with spaces, meaning we would save a lot of primitives in our buildings, not counting that we can save also polygons, meaning a better framerate for everybody, also, we can have too the so-desired custom uvw mapping, meaning the usage of less texture memory for using the appropiate parts of the texture...
I looked at the code of Prim importer. This script does just loading a prim which is already in the LindenLab style, meaning with the basic shapes (cube, sphere, torus...) and basic parametres (hollow, taper, dimple, etc). And it don't use a normalized file format, but the output of a script which runs in Blender.
so Prim Importer doesn't add anything new, save the ability to work off line. What is needed is something which gives the ability to import something really new, such as a VRML "indexedFaceSet" or an object in the .obj file. I cannot believe this isn't done by now. OBJ/3DS/VRML/... should have been importable since the begining for every reason already mentionned, I can't count the amount of people building their houses with maximum 10 prims because of sims restrictions (which makes logicaly ugly buildings), and the others that are building with 2000 prims (which makes verry slow frame rate, download time, heavy texturing,......) when it will use 10 to 20 time less vertexes and textures in a Mesh file. 50% of SL got verry ugly buildings, the other 50% can be way better (don't get me wrong, it has many beautiful places, but we're in 2008, and all those are looking like 10 years ago, thanks for windlight for the little more it added anyway). This would be the "middle" way, sculpties are overrated and if not a pro with, not looking good at all. It's suposed to please the maximum people on SL, but I just know 1 or 2 people building sculpties offline, the others are using "prefabs" sculptie, I can logicaly say that this option failed to attract people due to it's heavy knowledge requirement (for so less... in result).
I know that LL intention is not to have a ugly SL, nor to have a SL that goes verry slowly, but to have a beautiful place for their residents... And we all know the options to get SL in 2008 aren't that far away. I don't mention the amount of people who don't want a SL because of it's oldschool looking, nor the designers I know that laugh at me when I tell them I love SL, I just know that this option will be a boost in the SL economy, and of course a boost in registrations. (this is all about logic) I know a major problem would be that the people that are building with prims, or sculpties will get a hard time jumping on a new software (blender,3Ds maya,...) but what ? Why will they have privileges to keep their way to work, and the ones that knows more advenced softwares forced to do go under their knowledges to please the "I MAKE SL UGLY" builders and others, time to make everyone happy. This is all benefit, only a blind guy can kick in a golden mine without stoping by, LL, don't be blind :p (nice analogy isn it ?) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sub-task
Resolved
Normal
We'll leave this open for a while -- just wanted you to know it's on the radar.