
Project Two: Now Recruiting
Moderators: Moderators, Content Developer
- Drone_Fragger
- Posts: 1341
- Joined: 04 Dec 2005, 15:49
- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
It does make units take longer to build, and just because 'polies mean jack shit' doesn't mean you should go overboard and waste time on stuff the player will probably never seeDrone_Fragger wrote:*Cough* Polys mean jack shit. Go read caydrs article. UNless its like 100,000 Polys it doesn't mkae much differance.
I think the point was not "Poly's mean nothing! Free for all!"
But more like "Polycount is not the primary determinant of a models performance, rather there are other factors in the Spring core that are the primary chokepoints. As a result of this, the optimum polycount for performance in Spring is a good order of magnitude higher than what the community restricts itself too at times. Also, it is worth noting that a model with fewer moving parts can be higher poly, since the Spring engine pays a low price for rendering one large, static orbject, and a large price rendering several small animated objects."
But more like "Polycount is not the primary determinant of a models performance, rather there are other factors in the Spring core that are the primary chokepoints. As a result of this, the optimum polycount for performance in Spring is a good order of magnitude higher than what the community restricts itself too at times. Also, it is worth noting that a model with fewer moving parts can be higher poly, since the Spring engine pays a low price for rendering one large, static orbject, and a large price rendering several small animated objects."
Erm... polycount is less important than other factors, but it still matters quite a bit, especially with reflections and glowmaps being included in the picture.
That said, it's mainly not about polycount, it's about pathing and other factors, many of which appear to be worse since Spring moved to the new sourcecode. But I really don't expect this to remain a big problem forever.
That said, it's mainly not about polycount, it's about pathing and other factors, many of which appear to be worse since Spring moved to the new sourcecode. But I really don't expect this to remain a big problem forever.
- PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
- unpossible
- Posts: 871
- Joined: 10 May 2005, 19:24
- Charlemagne
- Posts: 174
- Joined: 18 Apr 2005, 17:59
It is moving, but slowly. I have been teaching myself some new technical approaches to address some specific needs, such as skinning organic models more effectively, and I am waaaay behind on my concept drawings that I was hoping to show off two weeks ago. But it is still creeping forwards, and certainly not dead :)
Imho, what the engine really needs for organic models is support for bones. The current system of cob scripts could be reapplied to skeletal models by replacing the parts with bones. Then you could have organic models with smooth continuations instead of segments. Of course, that'd be a pretty beefy project for a patch - weighted vertex support is nothing to sneeze at - but it would be the perfect way to get more organic models into Spring.
I think support for such a thing has more problems than that, frankly. We'd also need it to be thoroughly BOS-compliant, or it'd just result in a lot've static animations per character that would look pretty fuggly.
Personally, I'd like to see my request for a BOS-preview built into UpSpring completed... I know JC has a lot've more important things to do, though, and I really can't imagine anybody else having the skills to get this done
Personally, I'd like to see my request for a BOS-preview built into UpSpring completed... I know JC has a lot've more important things to do, though, and I really can't imagine anybody else having the skills to get this done
