[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Loki files for banruptcy protection.
Mark Collins wrote:
> > But perhaps the multi-talented Nurgle is also a grade A artist as well as
> > programmer, musician and writer? Personally, I'm at most bi-talented and
> > I know my limitations.
>
> Well, as I mentioned later in my original email, I'm planning ondeveloping a
> system that uses NURBS patches as well as IK. The advantage?
>
> Instead of spending a large amount of time trying to model a character
> face-by-face, you can use a define the control points more roughly, and let
> the software work out what goes where. Whether you do this in realtime or
> generate a more tradition mesh before the game actually starts (hell, you
> can even do it at design time if you wanted) is up to you (I'd probably do
> it when loadin the game, so the user can specify the detail level, a fast PC
> can have a high-poly count, a slow PC can have a low-poly count).
I don't think you can have done much work with NURBS - they are nothing
like the magic bullet you think they are. For gently curving surfaces,
they do save you entering polygons - but then providing your modeller
has some kind of a subdivision surface capability, you can do those
easy enough using polygonal bases.
The disadvantage of NURBs are when you need to accurately control the
shape of the surface - adding spikes and claws and stuff like that can
result in you using nearly as many NURBs as polygons.
It's not just me saying this. I was reading George Maestri's two books on
character animation and on page 32 of volume 1, he says:
"Mathematically, a smoothed polygonal surface is exactly the same as
a B-spline path. The next time some wacko tells you that patches are
better than polygons, just remind him or her of this little tidbit."
...so I just pass on his sage advice. He doesn't go so far as to say
that polygons are better than patches though...(and I know he's using
NURBS in his newer projects since he wrote that book).
...and of course a B-spline isn't a NURB - but the business of NURBS control
points being off the surface they influence can make for some pretty
wild animation glitches if you are using skeletal stuff on the control
points...but if you are heading off in that direction, you must have
already thought of that and have some kind of a solution.
> This does have several HUGE benefits:
>
> 1) Shorter development times - If you incorporate a generic IK-skeleton
> system, you only need to design the model using a small number of patches
> (can be done with 4 for each segment of the skeleton if you're not too
> concerned with detail), you can re-use the skeleton for different characters
> (a skel. for bi-peds and a skel for quadra-peds).
That may be true - but I'm doing that same thing with polygons - so no difference
there.
> 2) As mentioned before, you can tailor the models for the end-users system,
> add a degree of scalability and future-proofing to the game (imagine
> developing a game now, and it still uses maximum polygons on a card that's
> released in 5 years).
Yes - that's certainly a win for patches...although if your tools have a smooth
operator - then it's relatively easy to generate the high polygon count models
and use one of the MANY automatic mesh reduction schemes to simplify it.
Or just implement a VIPM scheme...that's not exactly difficult.
One of this years' SigGraph papers showed a 14,000 polygon model being auto-simplified
all the way down to 300 triangles with really very good results.
> 3) It just looks damn kewl, and imagine the marketing potential...
Does John Q Gamer know what a NURB is? (Do YOU know what a NURB is? Why "Non-Uniform"?
Why "Rational"? Why not just a B-spline?)
It *might* impress other games programmers - but I don't think you'll sell more games
as a result.
> If you use a similar system for props and the levels (Quake III does it to
> some degree), you can still reduce the total development cycle, and the
> minimum-skill level required by a significant degree.
OK.
> Of course, you'll need to have a good optimizing compiler to take advantage
> of it (unless some bastard decides to make a chipset that does it in
> hardware, which is only a matter of time).
>
> Think about it...
Well, I have thought about it - quite carefully in fact - and I *still* don't
see how this reduces the problem of generating art-work. Switching from
polygons to NURBS isn't going to help IMHO. Just knowing *what* to model
is an artistic problem - and that doesn't go away whether you work in
NURBS, Polygons, Clay, Ink, Paint or Charcoal.
NURBS make some things easier (smooth curves) and other things MUCH harder
(making branching structures for example) - you end up with a bunch of nasty
fillet NURBS that don't do much for the overall look of your model - but are
needed to prevent holes from opening up as things animate. Reducing those
to triangles on low end machines is going to do *bad* things to your low
end polygon count.
I'm not convinced...but you evidently are - so I guess you just have to try
it and show us the error of our ways.
----------------------------- Steve Baker -------------------------------
HomeMail : <sjbaker1@airmail.net> WorkMail: <sjbaker@link.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://prettypoly.sf.net http://tuxkart.sf.net
http://freeglut.sf.net http://toobular.sf.net