Slashdot Mirror
Software for the Realtime 3D Modeler?
Milo_Mindbender asks: "I've been involved in doing a number of games and other realtime 3d apps and I always run into the same problem: the 3d modelers that most artists use (MAX, Maya, Softimage, Lightwave...etc) are all heavily biased towards doing non-realtime rendering using raytracing or some other technique. While they can be used to make models for realtime 3D hardware, a very large number of their features don't map well onto realtime 3D hardware. For example many of the procedural shaders used by these packages map very poorly to a hardware shader's abilities, and similarly, if you want to use a hardware shader on some polygons, most modelers give you no way to see the effect while modeling."
"There are other problems too: modelers that have no concept of polygon strips/fans or that make it very hard to avoid generating polygons that will never be seen (the inside surface of a pipe for example). Even if you have the target 3D hardware on the modeling machine, it's rare to have the modeling windows look anything like the finished product. I'm wondering if anyone has run across a good solution to this. Possiblly a modeling package more geared to hardware capabilities, or some way of adapting an existing modeler to make it more hardware friendly by blocking or modifying features that 3d hardware can't handle. It would seem such a package could be cheaper too, since it wouldn't have to support as many fancy features."
How does Blender stack up? Aren't they going open source?
Both LW and MAX have gotten better in ways that you've described. MAX previews motion blur in OpenGL (Which as some of you know is VERY expensive to render...) and LW now does lens flares, hypervoxels, and fog in OpenGL as well.
LW's VIPER is pretty interesting too. What you do is you do a test render of your object and the resulting image is stored in a buffer. Then, let's say you want to play with the surface texture on it. Fire up VIPER and it shows you a low res version of the image you just rendered. When you modify the surface, it re-updates that image preview, but it only re-renders that particular surface that you're playing with. It's much faster feedback for getting a feel for procedurals than a full bore-render.
Is it real time? Ehh.. no. It's close. 2-3 seconds maybe? I agree with the author, though, that more could be done. Why couldn't they convert a proceedural into a texture and present that in OpenGL?
The good news for the author is that the industry (not just Newtek and Discreet) sees the value in having more real-time feedback. The next couple of major releases for the main packages out there will be very exciting for just that reason.
Take a look at gmax and Milkshape3D
Hmmm... lets look at the phrase "hardware capabilities"
"Hardware capabilities" doesn't have a single definition. Are you talking hardware like the Radeon 8500? (which is pretty sweet and fairly common among gamers) or are you talking hardware like the graphics chip in the Intel 810 motherboard set? (which is pretty weak but extremely common among the general public). Believe it or not, a huge number of games are still spec'd to run on low-end chipsets like the i810 because thats what consumers own. Sure, everyone you know has an 8500 or a GeForce4, but you're not a normal person if you're here reading slashdot. Normal people have old machines with slow graphics cards. A modeler that was designed for 8500 cards would be next to useless on a project aimed at i810's, and vice versa.
More importantly, "hardware capabilities" doesn't have a static definition. Graphics hardware is subject to Moore's law (except that the doubling time is even shorter than for CPUs). In the 12-18 months it would take you to write a high quality hardware-oriented modeling tool, graphics chips would run through at least two, possibly 3 generations. Do you design for the current hot chips, since those will be fairly common by the time your software is ready? Or do you try to guess what hardware will do in 18 months even though only a few hardcore gamers will own cards with those features when your tool is released?
Lets assume you've figured out whether you are going for serious gamer hardware or mass market hardware, and you correctly predicted what year you were targeting and guessed the feature set perfectly. Lets even assume you've written it and finished debugging it. Six months later (when the next generation of chips arrives), do you (a) throw away all your work or (b) invest another 6 months completely revising it because NVidia just announced some whizbang new feature that your user interface can't support?
Chances are, whatever you decide, pretty soon you'll find yourself doing exactly what Alias|Wavefront and Discreet and NewTek and etc. are trying to do: build the very best modeler you can, and let the hardware vendors catch up. You don't need that many more doubling times before all those slick features are "hardware capabilities."
Have patience.
Mods, please read this entire post before moderating, I get to the point in the last paragraph.
Just because a poster may not be verbose or even have a full understanding of the topic matter doesn't make a post off-topic. Instead, it is an opportunity for geniuses like yourself to give input. What you are reading right now is what we like to call a "discussion forum", where people come to talk. This occasionally means intelligent discourse instead of the tripe you're serving today.
As far as the subject at hand, I think that using the de facto game engine as the basis for a modeling tool isn't out of the question at all. You already have an API to move objects in three dimensions. You'd have absolute WYSIWYG if you used the quake engine as the basis for the game. Does "common sense" mean never using a readily avaiable codebase for a novel purpose? Bah. If you are making models for games, then why not use a hacked out game engine to do the modeling, like many game companies are doing internally anyway?Error: PANTS NOT FOUND. Press <F1> to continue.