|
|
|
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 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. That direction is perfect, Qarl. =D
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, @Miller, I think that is a good idea. How it is actually implemented is vary, but you are right the option should be available.
— 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 I agree Johanick.
I invite you to VWR-8145 where the discussion went more far I have to agree with you, Johanick... I hate sculpting for being so restrictive... and even, it has tons of polygons which I don't need in many cases... just think that we could even make an entire attachment as 1 prim with even less polycount that if it was built by prims, and not counting texture usage, because we would have UVW map support, and we could make split polygons easily... even we could use our own designs of the imported 3D geometry for other uses... or just take what we designed before to SL.
I know this has been a while and i am pretty much a newbie here but I can't keep my trap shut so here goes. I am trying to build stuff, trying to work in this archaic 3D environment. I strongly believe that the second Life concept has great potential. But the attempts by people who have so little confidence in their abilities that they will try to squelch competition by means other than their own ability will destroy the potential. Do you really think that second life will remain the only option. Great concept, but technology is growing rapidly and someone else WILL develop an alternative where everyone can create things as easily as possible. The 3d modeling capabilities within second life are rediculously primitive. Yes it is amazing what people have been able to do with they have here now, but people were able to do alot with stone tools also. Everyone that denies or tries to limit technology will eventually fail and their cronies with them. If this is the attitude at the top of this chain then everyone should go ahead and jump ship because there is no hope. Sculpties are great for meshes and organic shapes but there is no realistic way to create architecture of geometric shapes without using vector methodologies like is found in BIM programs that are being developed. There is a huge potential for the building design industry to use this format if you were friendly to it. And that's just one area of potential Who knows what else is out there waiting for this thing to advance. Make this stuff happen and the world will open up to you. Stop it and they will go somewhere else. Move forward and you will move into areas you can't even imagine. Have a little faith, and a little vision.
Dzonatas, is it possible to use that code for a third party client?
$License$ looks to me like still undefined. The patch posted here, as noted above, is just a demo. The comments in the patch show the many assumptions it makes. It is useful as-is only for fully convex objects that don't need their polar coords fixed. The patch was just a proof-of-concept, but as hinted early above, some LL had other business plans. The contributor agreement argument is null and void since LL has my contractor agreement on file, which LL only needs to honor, here and now, their signature next to mine, as they have before.
Since it was further noted after my last comment that LL is willing to reconsider a patch like this, then there may be hope again. However, what can be done in the http-texture is much preferable to sculpties, especially for complex objects. I don't see a reason to support sculpties anymore, but maybe they'll be used like a quick-preview to multiple prim object, which would just be a network-optimization for distant multi-prim objects. For example, if you have a complex link-set, the server could generate a preview sculptie. That way when you look at distant objects, you see just the preview sculptie. That could save bandwidth. Anways, if I ever update this patch again, it'll be applied to MonoVida Studio and written in C#.: Thanks Oh yes that is what we need to drop on the economy. Kill sculpties. Render hundreds of thousands of dollars worth of inventory useless and put thousands of people out of work.
Would you care to rephrase your statements and code in a manner that allows it to coexist with the existing technology in Second Life? Or do we need to alert the community that is paying the bills to what is going on? What you know of sculpties probably won't end. I don't see them being made useless, as you thought. There are other formats besides sculpties that will be supported, if not by LL then by other viewers. Talk about putting people out of work... ahem
The http-texture branch has the basics to enable other formats besides sculpties. It's not an end to sclupties... it's diversity! Ann, if any real 3D format gets supported in SL, it is enough to convert sculpties in it.
Of course it will be cool to have those "real" meshes in future and of course your patch has
But afaik no one can say when meshes actually are available for SL. And still making sculpties is nothing that is done by the way - any way. And there are quite a lot of great viewer projects, of which some love to have experimental features for the fun of experimenting and for the fun of how great experimental features sometimes work. I made an port to 1.22, I can mail it to you, if ok, Dzonatas, and if you like it, it would be great if you decided to upload it here again with the $License$ part in llimageobj.cpp and llimageobj.h replaced by an open source license text.
Thank you Dzonatas. In your previous statement you clearly and unambiguously stated 'I don't see a reason to support sculpties anymore". I would like to see an end to socio economic catastrophes dumped on Second Life by programmers that have no vested interest in the Second Life economy other than a code hobby. It is very easy to damage Second Life and anger thousands (as the poor guy that redid the pie menu discovered sadly). Therefore nothing should be attempted unless the question of "What will this do to the existing status quo in the economy?" is answered from all aspects of Second Life. If the answer is loss of hundreds of thousands of dollars then the programmers involved better be prepared to pay compensation. Second Life is not a programmer's hobby platform anymore.
Yichard, what are the logistics in converting from sculpties to this type of mesh support? Linden Lab mass converts? It is performed in code in the viewer so old versions see sculpties but new versions see meshes? The conversion must be exactly identical in all aspects. I.e.; the meshes will have to be stretchable as not all sculpties are perfectly formed and are stretched to achieve certain shapes. I am not a blocking entity. I am someone that wants to see every aspect and angle of this technology thought out from the technical, sociological, economical, and legal perspective. @Ann Otoole:
If you're worried about a straight conversion of sculpties to mesh, consider that existing tools already provide this functionality. As a sculpt must be created with external tools, the conversion to and from mesh is already very well understood. This includes tools such as Sculpt Studio, which pawn the mesh component off to an external server. As for conversion of standard prims to mesh, one can already convert to mesh using something like my prim library for Prim.Blender or Shack Dougall's Prim Composer. The ability to map existing textures, position, rotation, and scale information for multiple sculpts is already very well understood, as the texture (UV) coordinates are deterministic, and several tools support primitive information. So, if sculpts needed to be backported to meshes, this could already be done without changing any tools. In other words, don't fear the tools. This isn't a radical development change, so much as making what's already there more efficient. @Armin,
The public version of the patched file is under LL's license. Ann, there is an exact mathematical definition of a sculptie. So it is just a matter of transcoding to another format. This transcoding is done anyway for every prim, at time of rendering the scene.
As you point out, the difficulty is that at a moment there will be viewers able to see the new format, and some unable to do so. But this is only a matter of planning: have viewers able to see both. When the ancient viewers are outdated and no longer allowed, the conversion can be made at any time, and at any pace. After it is done, the new viewers no longer need to see the ancient format. There is no special difficulty here, just sound managing. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Resolved
Normal
(nice analogy isn it ?)
We'll leave this open for a while – just wanted you to know it's on the radar.