Talk:Comparison of 3d tools
Contents |
Rendering and scripting capabilities should be added.
I think it's important that at least some basic info on whether a renderer is included should be added... what type it is, if the app has network rendering abilities - and if so, how many nodes are included. It's equally as important as any of the info currently listed, and lets potential users know what optional add-ons need to be aquired to complete a basic tool set. Creation is only one aspect, and output shouldn't be limited to file formats alone.
The same goes for scripting, with at least a note if it's included, or as an add-on - and in what 'language'.
RCRuiz (11-01-2006) Well I think that will be good to mention as a note that there are a lot of patch and extra compilations of blender for extending the render capabilities of blender to other render engines like to indigo, PovRay, Mentalray, and others
UV Unwrapping
Can whomever added the Architectural, LSCM, and ABF++ please explain what these in fact are? Or provide links with details to how they actually work.
As far as I'm aware there is no special UV systems for Architecture, they're just objects like everything else, they just happen to be houses.
LSCM looks like a rudimentry version of pelt mapping at best, and ABF++ isn't clear at all. No, Max has neither of these named what they are, but possibly it's toolset has equivilant functionality.
Salmonmoose 12:33, 24 September 2006 (UTC)
Actually LSCM and ABF++ are more advanced algorithms than pelt mapping and provide superior results
As one UV mapper put it "Pelt mapping doesn't hold a candle to LSCM unwrapping,"
http://forums.luxology.com/discussion/topic.aspx?id=10966
and the quality improvement of ABF++ over LSCM is also quite large.
"The numerical and visual comparisons throughout the paper consistently indicate that ABF and its extensions create angle preserving parameterizations with significantly lower stretch than linear angle preserving methods (LSCM/DCP). "
(Bruno Levy is one of (the?) primary researcher behind LSCM and more recently ABF++ ...)
http://alice.loria.fr/publications/papers/2004/ABF_plus_plus/abf_plus_plus_temp.pdf
LSCM stands for Least Squares Conformal Mapping ABF stands for Angle Based Flattening ABF++ is an advanced version of angle based flattening and is the current 'state of the art' for unwrapping algorithms.
Silo 2 and Modo 2 added LSCM based tools. With its last release Blender moved from LSCM to the more advanced ABF++, and is currently the only tool that I know of to use the more advanced algorithm.
LetterRip 17:51, 24 September 2006 (UTC)
Keybindings
Is the default keybindings really necessary for a comparison at this level? I think that each app's own page would be a much better place for showing the hotkeys, as the difference in workflows and GUI mean that a tool by tool comparison chart is convoluted and inaccurate.
JDex 21:03, 01 October 2006 (UTC)
- In some ways I agree. However this, or a sheet similar to this, could be useful to users of one ap who find themselves having to learn another for a task. There are operations (such as viewport control) that are found in almost every app so it really comes down to "What is the hot-key for _X_ operation in _Y_app_". --Mummey 21:38, 1 October 2006 (UTC)
- Of course I see that side of it, but it's not as if the individual will be deciding which app that will be, that decision will be made, and they will be going to the apps page itself, as the goal is to learn it, not compare it.--JDex 23:28, 1 October 2006 (UTC)
- I think theres some merit to moving the information to a page on it's own, as it's going to blow out to something huge. Salmonmoose 00:46, 2 October 2006 (UTC)
- I'd agree with moving it to its own page for the keybinding comparison...
LetterRip 02:10, 2 October 2006 (UTC)
- I concur, and I don't see any dissenting opinions. So who wants to do it? --Skybum 19:00, 18 January 2007 (UTC)
Blenders wiki has some images that make the Keys easier to see and understand, I'll see if we can donate them for usage here. See this wiki page for an example
http://mediawiki.blender.org/index.php/Manual/Hotkeys
LetterRip 00:27, 7 October 2006 (UTC)
Painting and texturing
When I added the painting and texturing, apparently I wasn't clear
Node Based 2d paint 3d paint Multi Objects Layer Based Multi Materials Vertex Paint
Node based materials can be generated via a node based system
Multiobjects is paint across or texture across multiple objects continuously
Layer Based is paint in different layers as per paintshop
Multi materials is paint multiple materials at the same time
anyone have suggestions of how I can make things clearer? Perhaps a page defining what the different categories mean?
LetterRip 08:54, 13 October 2006 (UTC)
I clarified the headings, and changed the software programs that I didn't know to 'dunno'. It probably would have been safe to change them all to 'No' except Modo and Cinema4D (via bodypaint 3d).
LetterRip 20:11, 14 October 2006 (UTC)
"General Info"
Any text like that is going to be misleading or biased. The purpose of this page is the exact opposite. (Provide the details of what the app contains, let the reader make up his/her own mind.)
As a result, I deleted the text that someone posted. If you disagree, feel free to pull it back up and add it back in.
--Mummey 19:12, 3 November 2006 (UTC)
Additional import/export formats?
Hi, I've been adding in Art of Illusion, the software package that my firm uses for architectural renderings. In the import/export sections, there are a number of formats which AOI supports that aren't listed: namely, DEM, STL, POV, and GEO. I'm wondering if it would be worth including them in this table. Seems to me that STL & POV, at least, would be worthwhile. What do the rest of you think? Skybum 18:57, 18 January 2007 (UTC)
Miscellaneous Discussion
I think that a discussion of purely modeling aspects does all these products short shrift. I would say we need a real in-depth comparison here, comparing dynamics, scripting languages, interfaces, renderer integration, and userbase.
Bonedaddy 16:22, 7 July 2006 (UTC)
Nevermind, I'm a dope. There's clearly sections for that.
Bonedaddy 16:23, 7 July 2006 (UTC)
I think it's better to list workable polycounts as a list rather than a table; simple maths prooves that if a package can support 100,000 polygons it can support 50,000 - it's redundant to list both ;) - I feel this is also somewhat of a spurious number, I've worked in max on million plus polygon models; "workable" is proportionate to "patience" :)
Salmonmoose 07:21, 10 August 2006 (UTC)
For workable polycounts we need to specify better - is that in raw form or subsurfed form? Are we talking quads or tris? Single object? Any hidden geometry? What processor? If talking subsurfed poly count and tri count then that is quite a bit different from quad count without subsurf... For Blender I used my own hardware (2500+ AMD with 512 meg ram that is sharing memory with my ati card) with subsurfed on and it can handle 500,000 quads (including the subsurfed) just fine. However if we are talking true geometry, then it might be lower. Also for workable are we talking deformation with armatures etc, or are we talking sculpting, or are we talking low level polygon tools?
Tom Musgrove 02:12, 14 September 2006 (UTC)
I feel that the comparison table for format support needs to be much further developed, first I recommend splitting into import and export. Secondly I think we need to convey instead of straight yes/no what features of the exporter are supported and possibly whether it is considered to be 'Good' support.
What I suggest for the 3d formats is
Geometry Uvmaps Textures Materials Rigging Constraints Morphtargets Animations
GUTMaRCMoA
and also possibly
Scene, Lights, Cameras, Particles, Physics, and other properties (although only a few formats contain such) - perhaps a score could be used to represent to the 'level' it is supported
so
1 - Geometry; 2 - UvMaps; 3 - Image Textures; 4 - Materials; 5 - Rigging; 6 - Constraints; 7 - Morphtargets; 8 - Animations; 9 - Scene; 10 - Lights; 11 - Cameras; 12 - Physics; 13 - Particles
If all features of the format are supported then A for all can be used perhaps. or use score over max score - so all supported for a format that has everything including partlces would be 13/13. Whereas only supporting Geometry would be 1/13.
Tom Musgrove 06:40, 14 September 2006 (UTC)
We also need some way to indicate which version of the software is being refered to - Maya Foundation, Maya Complete, Maya Unlimited? XSI Essentials, XSI Advanced? The various Cinema 4D bundles; and the various configurations of Houdini that can be purchased.
Tom Musgrove 07:01, 14 September 2006 (UTC)
It may be that some of this stuff shouldn't really be here. I agree with bonedaddy that the "workable" polycount is very dependent on the system used and the users own patience, every application can support millions of polygons the only possible comparative there is how compact the data structures used are, i.e. how many polygons per megabyte of ram.
The supported file formats should probably be reoriented to a vertical layout, there are far more file formats than applications (any one of these applications these days supports out of the box up to thirty or forty formats including various revisions and variations of those formats, fbx5, fbx6, vrml1 etc).
To be honest to make this useful rather than dickwaving it would be better to have tables that indicate more useful information for actual users. e.g. comparative keyboard shortcuts, comparative viewport modes, stuff like that, because all the applications basically support the same things, "feature" lists can be found at the websites and don't tell you to what level things are supported or anything about the implementation, feature lists here will do the same thing (so I'm not altogether convinced that it's a worthwhile page topic as it stands).
Per-Anders 07:04, 14 September 2006 (UTC)
- I'm of two minds about that. One question is, who is the target audience for this table. Is it people looking to start in 3D? In which case knowing that for instance ZBrush, Wings 3d, and Modo, have no animation, or particle support would be important. Is it existing 3D users trying to mix and match a new pipeline? Is it heavy users of one tool looking to migrate to another? I definitely think your idea of compartive keyboard shortchuts, comparative viewport modes are an excellent idea. It might also be a good idea to do a 'rosetta stone' for terminology. For the formats support I think detailed information as I suggested above can very much help people who need to interoperate between various software - but just yes/no isn't too useful. Perhaps even noting which are the preferred formats might be a good idea. Have a look at how polytrans organizes their format support matrix. http://www.okino.com/conv/filefrmt_3dimport.htm
Tom Musgrove 07:29, 14 September 2006 (UTC)
Just to add, I really don't see the point of the texture/rigging sections. These are basic features common to all applications and it seems almost tautological to show such lists here. In the rigging section every app will be "yes" for every area apart from Wings, Modo and Z-brush simply because they're modeling tools not animation tools. Only some low/mid end animation software would lack any of this (perhaps Strata?).
Per-Anders 07:24, 14 September 2006 (UTC)
Per, I think it could be compressed into 'character animation' that could distinguish to the very primitive animation capabilities that some software such as Strata provides. Perhaps simple animation, character animation, particle, then assorted simulation? Physics, Softbody, Cloth, Fluid, Crowd? That would remove most of the redundant checkmarks, and would differentiate between the various 3d suites in addition to differentiating between the non animation focused software.
Tom Musgrove 08:14, 14 September 2006 (UTC)
That would be 'I agree with salmonmoose blah blah blah....' ;) The intent for this page, and similar pages, is an 'at a glance' overview of the features of various applications.
If there is a table where the 'big' packages support everything, perhaps we should just list them together and make a note under the table.
The file format can be split into 2 sections, that's a good idea. When rating packages with a score on how well they perform certain actions, can we make that quantifyable, for instance, I personally think 3dsmax has excelent modeling tools when compared to maya, but that's just because that's what i'm used to, supporters of packages generally like the tools they come with, that's why they support them.
Salmonmoose 22:49, 14 September 2006 (UTC)
No it's not possible to quantify that, because it's a contentious issue with software zeoltry abound, and requires poeple to have knowledge of each applications methodology to a similar level. Very few people have that and there's no way of filtering this to only the userful input, for instance I would dispute what you say about Max's tools and suggest their workflow is a weak point. This sort of thing is why we don't allow software comparisons on the forums, and probably why we should steer clear here. It's also why these sorts of tables aren't much use escept to marketeers, and why stuff that explains how to do common tasks in each would probably be better (and give the casual reader a better basis to judge the workflow/implementation of each application).
Per-Anders 22:04, 14 September 2006 (PST)
Hi all, here are the categories for a comparison chart that I had developed, personally I think there are a lot of useful categories that could be added from the below to the comparison we are doing. Also I think the organization I have below might prove more useful.
- Modeling
Polygon Modeling Box Modeling Nurbs Metaball Sculpt Tools Splines Patches Implied surface modeling
- Texturing
Brush support Alphamap support Layer/channel support Presets Animated Textures Volumetric Textures Procedural Textures Image Projection Tiling
- UV mapping
- Animation
Rigging Motion Capture Pose Libraries Animation Libraries Prebuilt Rigs Synthetic Motion
- Lighting and Rendering
Built in/Native Render Speed Accuracy Feature set Shader Support Ease of Use Licensing Live Preview/Incremental Update RIB support External NonRIB support
- Simulation
Crowds Cloth Fluids Fire and Flame Smoke Solid Physics Soft body Physics Hair and Fur Ocean and Waves
- Wizards
Heads People Cars Animals Terrain Plants and Trees Creatures Architecture Hair and Fur Cloth
- Scripting
- Programming
Macro
- Game Engine
- Interoperability, Architecture and Scalability
Cross Platform Import tools Export tools Embedding Network rendering Multithreaded Multiprocessor 64 bit support
- Interface and Configurability
Gizmo's Collapsible Pallets Key bindings Configurable Mouse bindings Configurable Help System Tutorials
- Pricing
Price Standalone Price With common addons Maintenance Price
LetterRip 22:09, 15 September 2006 (UTC)
- This page was last modified 19:06, 18 January 2007.
- This page has been accessed 2,810 times.
- Content is available under GNU Free Documentation License.
- About CGWiki
- Disclaimers
|
