Because there are a good portion of engine devs and content producers/modders who have such equipment, so if you want to keep them with the project, it would make sense to not alienate their systems.Zenka wrote:I don't get it. how can people suggest that commercial games may have a GF6 requirement and non-commercial games MUST be lower.
If lack of opengl 2.0 support is the problem. you can get an opengl 2.0 supporting card for 40$.
The latest version of spring is released this year. Name one game released this year that uses 500+ units, with a fully 3d rendering engine, and runs on your GPU from 2002. (take in account your CPU and memory also come from that age).
Why must the engine go forward if the hardware that runs it must remain the same?
Spring + decoupled renderer
Moderator: Moderators
Re: Spring + decoupled renderer
Re: Spring + decoupled renderer
The only real complaints I saw about OGRE had to do with file-conversion and rendering tests.
However, all of this is beside the point.
The first real question here is, what does OpenGL 2.0 offer that is a compelling advantage? Having seen what Trepan's been doing with it, I suspect that there are several key advantages- speed from rendering more stuff on the GPU, more efficiency, better support of shaders. I don't know much about how it all works, but that's what it looks like.
The second real question is, is that enough to abandon the low end of the userbase? If it were up to me, I think I'd have to answer, "yes". There aren't enough people who'd be left out, and the barrier to entry, i.e. the cost of upgrading hardware to the spec, is fairly minimal (for non-laptop people- imbaczek is screwed). I've seen bargain-basement prices on cards that should be fairly good, and meet spec- the GeForce 6800 series, for example.
However, is that an either/or choice? It shouldn't be. Spring already supports some OpenGL 2.0 spec stuff, yet retains core compatibility with 1.X specifications. Why should this change?
The third real question is, is it worth bringing all of the "garbage" from an engine like OGRE or Horde, both of which are, from what I've been reading, full-featured engines, and not just rendering systems awaiting content specifications?
Now that I've done a bit of reading, I think the answer to that is, "probably not". Why inherit all of the game-design choices inherent in an engine? For example, OGRE has certain things that it expects a mesh to have. We'd need to convert all of the .S3Os, and it'd probably be painful- auto-conversion applications are, for various reasons, usually sucky, so we're looking at a lot of hand-tweaking of literally thousands of items here.
Or crappy conversion, like we saw, and still see, with 3DO. After all the work that went into .S3O, and making it not suck... that'd be silly. Child, I know you mean the best for us with this, but please understand- if you haven't built content for this engine, you're just not going to get what we're dealing with, here. It's not just a mesh --> origin --> rebuild the normals sort've conversion we're talking about- the .S3O spec includes all sorts of stuff, that's very specific to Spring, such as model heights, a hitsphere, a very specific glowmap / reflectionmap format, etc., etc., etc.
As much as I am frustrated that we don't have a way to do RK yet, if I had to trade that for, say, rebuilding every object for P.U.R.E. again, I'd walk away from it- we're talking months of time down the drain here, even if everything works pretty well. Whatever conversion was being done internally would almost certainly have to include an external set of tools, for game designers to work with content- without it, we'd be at the mercy of whatever your automated process did, and having seen that with .3DO, I don't think anybody here is going to be very trusting about that.
Why not just pick the lightest-weight pure renderer possible, preferably one that supports a dual rendering path, implement our file formats and shaders in it, and then work with the team to get things like COB animation working properly again, before going further?
I'm not really sold on including a lot of stuff we don't need- the only thing about Horde that is intriguing, given the epic scale and detail-levels required by Spring, is that it'd give us a third model format. But why not just use a rendering engine, and port that part over when the rest of it works again?
However, all of this is beside the point.
The first real question here is, what does OpenGL 2.0 offer that is a compelling advantage? Having seen what Trepan's been doing with it, I suspect that there are several key advantages- speed from rendering more stuff on the GPU, more efficiency, better support of shaders. I don't know much about how it all works, but that's what it looks like.
The second real question is, is that enough to abandon the low end of the userbase? If it were up to me, I think I'd have to answer, "yes". There aren't enough people who'd be left out, and the barrier to entry, i.e. the cost of upgrading hardware to the spec, is fairly minimal (for non-laptop people- imbaczek is screwed). I've seen bargain-basement prices on cards that should be fairly good, and meet spec- the GeForce 6800 series, for example.
However, is that an either/or choice? It shouldn't be. Spring already supports some OpenGL 2.0 spec stuff, yet retains core compatibility with 1.X specifications. Why should this change?
The third real question is, is it worth bringing all of the "garbage" from an engine like OGRE or Horde, both of which are, from what I've been reading, full-featured engines, and not just rendering systems awaiting content specifications?
Now that I've done a bit of reading, I think the answer to that is, "probably not". Why inherit all of the game-design choices inherent in an engine? For example, OGRE has certain things that it expects a mesh to have. We'd need to convert all of the .S3Os, and it'd probably be painful- auto-conversion applications are, for various reasons, usually sucky, so we're looking at a lot of hand-tweaking of literally thousands of items here.
Or crappy conversion, like we saw, and still see, with 3DO. After all the work that went into .S3O, and making it not suck... that'd be silly. Child, I know you mean the best for us with this, but please understand- if you haven't built content for this engine, you're just not going to get what we're dealing with, here. It's not just a mesh --> origin --> rebuild the normals sort've conversion we're talking about- the .S3O spec includes all sorts of stuff, that's very specific to Spring, such as model heights, a hitsphere, a very specific glowmap / reflectionmap format, etc., etc., etc.
As much as I am frustrated that we don't have a way to do RK yet, if I had to trade that for, say, rebuilding every object for P.U.R.E. again, I'd walk away from it- we're talking months of time down the drain here, even if everything works pretty well. Whatever conversion was being done internally would almost certainly have to include an external set of tools, for game designers to work with content- without it, we'd be at the mercy of whatever your automated process did, and having seen that with .3DO, I don't think anybody here is going to be very trusting about that.
Why not just pick the lightest-weight pure renderer possible, preferably one that supports a dual rendering path, implement our file formats and shaders in it, and then work with the team to get things like COB animation working properly again, before going further?
I'm not really sold on including a lot of stuff we don't need- the only thing about Horde that is intriguing, given the epic scale and detail-levels required by Spring, is that it'd give us a third model format. But why not just use a rendering engine, and port that part over when the rest of it works again?
Re: Spring + decoupled renderer
Fair enough, no reason to get upset with me.child wrote:smoth wrote:I'm sorry, the statement "not a good engine" is a bit too subjective for me. It really depends on the requirements of a project. In the end some things serve the purpose well and others not.
Instead of leaving a 2 sentence reply, why dont you elaborate why you think it's not a good engine and how have you used the engine?
I found the documentation lacking, features were not well integrated and mostly existing on several other branches rather then part of the core. For the most part Ogre had many nifty branches but it was not fun merging them to acquire features which the wiki(most outdated last I checked) listed as part of the engine. Maybe I expected too much, I am not sure, sure Ogre has some nifty graphical features and the particle stuff was nifty but it felt most cumbersome and in the end I would rather work with the feature poor irrlicht.
For what it does, I like the spring engine, yes, large areas need refactoring and decoupling is neat but I do not like a sudden change over to an engine that when I began to really dig in was not much for substance.
That is just my opinion and feel free to ignore it.
Re: Spring + decoupled renderer
Lets not get ahead fo ourselves, we've yet to see our existing rendering compile without simulation and vice versa. We should at least fullfill the rendering thread goal before moving to the rendering engine goal.
Re: Spring + decoupled renderer
Oh, I know. I'm being a bit silly. And, since I'm completely unqualified to have an opinion on the technical merits, I'm just opining anyhow.
In the end, if it's a better mousetrap, that's still a mousetrap, then I'm happy. I just don't want us recycling a beartrap, when a mousetrap is what we wanted.
In the end, if it's a better mousetrap, that's still a mousetrap, then I'm happy. I just don't want us recycling a beartrap, when a mousetrap is what we wanted.
Re: Spring + decoupled renderer
Sounds terribly scary. This could be the end of Spring.
Re: Spring + decoupled renderer
Argh, pretty much the way it works is that mousetrap sometimes has tons of bells and whistles then you find out the damn thing has no trap mechanism.
Re: Spring + decoupled renderer
Would this change lead to fixes of poor nvidia 8 series performance and issues running things like dynamic water and sm3?
Re: Spring + decoupled renderer
Not sure, the dynamic water is just a shader IIRC. As far as poor nvidia performance, I have no idea. Tobi found a few areas that may have been the culprits, I am not sure if they were fixed in this version.LordMatt wrote:Would this change lead to fixes of poor nvidia 8 series performance and issues running things like dynamic water and sm3?
Re: Spring + decoupled renderer
My 8800GTS 512 does just fine with everything ramped up (apart from water because its buggy, and grass because it is FUGLY and distracting).
it might not have the blazing FPS it does in other games, but the actual performance level is far from 'poor', even if less than expected.
it might not have the blazing FPS it does in other games, but the actual performance level is far from 'poor', even if less than expected.
Re: Spring + decoupled renderer
Is it strange that you actually need some hardware to run a 3d rts?imbaczek wrote:I'd gladly do that if you know a way to put in my Intel 945-based laptop.
Might be the reason Spring runs on an Intel 945. And devs are more important then any graphical stuff there might be.Nemo wrote:Because there are a good portion of engine devs and content producers/modders who have such equipment, so if you want to keep them with the project, it would make sense to not alienate their systems.
Still I think there might be a time you actually need to leave your notebook alone for playing 3d rts games. They are not made to run games, and Spring happens to be one.
But that time isn't here yet. So no need to worry yet ^.^'
Re: Spring + decoupled renderer
As I said, it runs fine on this particular hardware thankyouverymuch again.Zenka wrote:Is it strange that you actually need some hardware to run a 3d rts?
I'll put it other way - if you took out support for low-end hardware, you'd take out my ability to make patches, hunt for bugs, etc.
Re: Spring + decoupled renderer
As much as I want normal map shaders and such built into the engine properly, I would really be sad to see LUA opengl calls go.
If I can choose between 10k polygons I can do anything I want with or 50k that I can do whatever the engine does, I take the first anytime.
If I can choose between 10k polygons I can do anything I want with or 50k that I can do whatever the engine does, I take the first anytime.
Re: Spring + decoupled renderer
This sounds like a huge project. I'm always a bit wary of such large rewriting endeavors; personally, I prefer heavy refactoring. There's lots of articles on the Internet about the topic, e.g. http://www.joelonsoftware.com/articles/ ... 00069.html.
That said, I don't know the Spring codebase well enough yet, and it really might be nearly impossible. But on the other hand, it seems we will need to refactor anyway, since the simulation has to be separated from the rendering, which is a project more or less separate from dealing with a new renderer, isn't it? So why not start in that direction and decide the renderer issue later?
In any case, hats off to everyone who even considers starting something like this
That said, I don't know the Spring codebase well enough yet, and it really might be nearly impossible. But on the other hand, it seems we will need to refactor anyway, since the simulation has to be separated from the rendering, which is a project more or less separate from dealing with a new renderer, isn't it? So why not start in that direction and decide the renderer issue later?
In any case, hats off to everyone who even considers starting something like this
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Re: Spring + decoupled renderer
That being said, I'd sooner create a donation drive to buy you a new laptop than I would promise spring will be fine running on an intel 945 for the next 5 years. I can appreciate your usefulness... but we can't reasonably let one hardware setup for one developer hold back the entire project if legitimate progress is to be made.imbaczek wrote:As I said, it runs fine on this particular hardware thankyouverymuch again.Zenka wrote:Is it strange that you actually need some hardware to run a 3d rts?
I'll put it other way - if you took out support for low-end hardware, you'd take out my ability to make patches, hunt for bugs, etc.
This all being said, lets wait for this to stabilize a bit in specification... I have yet to see any hard figures on what exactly the result of this experiment will be anyways, and hopefully we won't have to make a final decision for a reasonable period of time anyways.
Re: Spring + decoupled renderer
Even I change my boxes more often than every 5 years, no worries here 
But currently there's no reason to drop support for very low-end (but very popular) hardware.
But currently there's no reason to drop support for very low-end (but very popular) hardware.
Re: Spring + decoupled renderer
Using Ogre or Horde might have a considerable CPU impact, because you have to go from spring -> opengl to spring -> general 3d engine -> 3D engine OpenGL implementation -> opengl
Spring is usually already CPU limited, so I wonder if that is a good move.
Plus I think you'd get a lot more credit for abstracting and refactoring the model rendering and then adding a better common 3D model format.
Spring is usually already CPU limited, so I wonder if that is a good move.
Plus I think you'd get a lot more credit for abstracting and refactoring the model rendering and then adding a better common 3D model format.
Re: Spring + decoupled renderer
I think it would be foolish to limit ourselves to that single renderer too.
Nor should we chase the high end. While we're buying high end hardware, the vast majority of PCs do not use high end machines, the vast majority of gpus sold are not on dedicated cards, and although we buy these high end cards, those machines they replace are still there.
We should not keep raising the limit for new entrances to our community using hardware when there is no need to. Use a fast renderer for the slow machines and give the end user a fancy renderer for fancy machines. The engine should be scalable, and it should be the mod if anything that determines whether it can run. Hardware should only limit what can be turned on, not whether it can run at all.
Nor should we chase the high end. While we're buying high end hardware, the vast majority of PCs do not use high end machines, the vast majority of gpus sold are not on dedicated cards, and although we buy these high end cards, those machines they replace are still there.
We should not keep raising the limit for new entrances to our community using hardware when there is no need to. Use a fast renderer for the slow machines and give the end user a fancy renderer for fancy machines. The engine should be scalable, and it should be the mod if anything that determines whether it can run. Hardware should only limit what can be turned on, not whether it can run at all.
Re: Spring + decoupled renderer
AF: +1
also, talking about performance without actually having something working is pretty much an academic discussion.
BTW child: what's the framerate of a renderless client? or, more precisely, what's the cpu usage?
also, talking about performance without actually having something working is pretty much an academic discussion.
BTW child: what's the framerate of a renderless client? or, more precisely, what's the cpu usage?
Re: Spring + decoupled renderer
Wow, a lot of posts over the last few days.
From what I get most of you guys have concerns about adding a restriction for low-end pcs. someone said it right, it should be up to the mod to define the limits. so no need to worry, ogre will work out just fine.
@smoth: nah, no hard feelings. I wasnt angry, i just wanted to know what bothers you there when you said that you didn't like Ogre.
@jcnossen: i'm sorry, but i dont see the pros of creating another visual-format which isnt closely tied to the renderer. as i see it i would have to design the format on its own and then hack the renderer to play along. i wont do that. also im not doing this for the credits i might get. i just want to help. and i think i help the most when i tackle the thing that pisses me off the most, and thats the cluttered opengl rendering code.
@imbaczek: i can't give you real numbers since the game lacks a gui to start off a game. also i can't garantee that i didn't break something along the way. so a quick test is non-trivial at the moment.
From what I get most of you guys have concerns about adding a restriction for low-end pcs. someone said it right, it should be up to the mod to define the limits. so no need to worry, ogre will work out just fine.
@smoth: nah, no hard feelings. I wasnt angry, i just wanted to know what bothers you there when you said that you didn't like Ogre.
@jcnossen: i'm sorry, but i dont see the pros of creating another visual-format which isnt closely tied to the renderer. as i see it i would have to design the format on its own and then hack the renderer to play along. i wont do that. also im not doing this for the credits i might get. i just want to help. and i think i help the most when i tackle the thing that pisses me off the most, and thats the cluttered opengl rendering code.
@imbaczek: i can't give you real numbers since the game lacks a gui to start off a game. also i can't garantee that i didn't break something along the way. so a quick test is non-trivial at the moment.