How much time are we doing this?? Is it just me or does that lack something called sense?
Well, I still know what you mean. I personally contribute about 30+ hours a week to it, and the other developers contribute about 10. I'll keep the project going with new devs as long as I can.
-maxx
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you explain in more detail how this project is different from VRML already deployed on the web?
Another thing... the project as you describe it resembles me massive multiplayer RPG. Am I right? If not - what is the difference from something like "Ultima Online" game, just in 3D?
And, question: in case you want to build networked virtual reality world shared by multuple users (as I understand it), why do you try to start from scratch and develop your personal engine on top of raw opengl commands (I saw the source), and not use something like Crystal Space or other ready and powerful toolkit to build your idea on top of it?
Is it out of curiosity how to build your 3D engine?
Just interesting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The other post... by dmagick, is very old. You reffered to VRML and the web project, that was mCode's original goal. This was changed about a year and a half ago. The current mCode project is working on a 3d engine, like you inferred. It is a multiplayer RPG, but I cannot add the term "massively" to that. The required technology, the required system, will likely be too expensive / too "top of the line" for wide use at least until the next "wave" of computing upgrades.
The reason we aren't using a pre-existing library like crystal space, is a) we are, and b) we don't have to. We are using various preexisting libs for tasks like physics, math, accessory functions,etc. We will likely recode these later with our own code if we need. Also, we use fmod for sound. You referred to "raw opengl commands" in a derogatory sense. It's really just the opposite - even though assembly was the first programming language, it is still in wide use - why? Because it's the most powerful. We have more freedom, and have more power over the minute aspects of our engine if we write it from scratch and by hand. Also, some of the optimization routines in CS make it unsuitable. Paramount to mCode is the graphics. The polycounts of the models we work with are high enough to make the program restrictively demanding.
Any more questions? We're happy to answer them... also, if anyone has any ideas for a new name for the project (replacing "mCode") please post a message!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your answers. They clarified a lot of things to me.
Yes I have some more questions. Hope I'm not annoying (I personally love when people give constructive crticism to me, or even ask questions that may lead me to think of better ways to do things).
You mentioned "very high polygon count" and "demanding" code that need too much hardware horsepower (did I understand it right?).
Question (actually two questions):
a) Why is that? What really make the application you guys develop so unique that it needs to render pictures with better detail/realism than current FPS shooters do with today's hardware?
The images rendered by current top games like Unreal 2, Stalker(http://www.stalker-game.com - gotta see it!), or HalfLife 2 have stunning realism level and very high model detail.
In the same time I did succesfully run Unreal 2 game on Voodoo 3 card (that is thought outdated one theese days) with medium-low rendering quality and at interactive frame rates. This means that even old cards like TNT2 or Voodoo 3 have enough power to achieve acceptable visual quality.
b) Following the first question: what about "scalability", ability of application to *adapt* to lower-end hardware by reducing amount of detail of the content (pictures) that it displays.
---
Actually, I am very interested in your project (partly because it seems that you are really serious about your goals, and I like it).
I run my own project that is close to what you guys try to do (http://realitystrike.sourceforge.net) that I opened about 3-4 month ago, that's why I am so interested.
If you wish, we may exchange ideas and help each other by exchanging ideas and source code.
Thank you again.
Regards,
Track
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
*corrections - restrictively demanding means that the system requirements will be INCREDIBLY high by current standards (assuming 2.4 GHz is near top-of-the-line). We may use some portions of the CS code later for trivial things, if / when this happens, it will be attributed and credit will be given in credits.cpp / our public info.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not at all... this is why this forum exists. You're perfectly welcome to ask questions.
To answer your questions, we did not set out to make a "game", nor a "game engine". It did end up being something along those lines, but it must be said that we are not writing the program for the "enjoyment of the end user". If we were writing a game, you would be right to wonder why we are putting so much emphasis on our graphics. We are essentially writing a game engine, but as a a massive tech demo. We are pushing the graphical capabilities on current hardware as far as they'll go, and then some. Why? Because we can. We are trying to recreate reality, how succesful in that only time will tell... but we'll definatley get a very capable engine out of it for anyone's interested work to run on.
One note about older hardware - the graphics card must be able to support OpenGL 1.4 - this is fairly recent, so only newer cards willl work. For now, glide and dx compatibility is not an issue since we don't use them.
I took a look at Stalker, and it is very pretty. It is about our goal for now. That only goes to show, that our project is possible. They are a running the X-ray engine, which as far as I can tell is internal and proprietary... we'd have no means of using it much less anyone else.... you can think of our project as an open-source X-ray or a next generation crystal space.
As for exchanging ideas.... we're kind of in the middle of some major updates right now, but once these are done (the next few days), ill take a look at your engine and we're always open to cooperation with other projects.
-maxx
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Khm.. How much time did you say you guys are doing this "grand experiment"?
How much time are we doing this?? Is it just me or does that lack something called sense?
Well, I still know what you mean. I personally contribute about 30+ hours a week to it, and the other developers contribute about 10. I'll keep the project going with new devs as long as I can.
-maxx
Can you explain in more detail how this project is different from VRML already deployed on the web?
Another thing... the project as you describe it resembles me massive multiplayer RPG. Am I right? If not - what is the difference from something like "Ultima Online" game, just in 3D?
And, question: in case you want to build networked virtual reality world shared by multuple users (as I understand it), why do you try to start from scratch and develop your personal engine on top of raw opengl commands (I saw the source), and not use something like Crystal Space or other ready and powerful toolkit to build your idea on top of it?
Is it out of curiosity how to build your 3D engine?
Just interesting.
The other post... by dmagick, is very old. You reffered to VRML and the web project, that was mCode's original goal. This was changed about a year and a half ago. The current mCode project is working on a 3d engine, like you inferred. It is a multiplayer RPG, but I cannot add the term "massively" to that. The required technology, the required system, will likely be too expensive / too "top of the line" for wide use at least until the next "wave" of computing upgrades.
The reason we aren't using a pre-existing library like crystal space, is a) we are, and b) we don't have to. We are using various preexisting libs for tasks like physics, math, accessory functions,etc. We will likely recode these later with our own code if we need. Also, we use fmod for sound. You referred to "raw opengl commands" in a derogatory sense. It's really just the opposite - even though assembly was the first programming language, it is still in wide use - why? Because it's the most powerful. We have more freedom, and have more power over the minute aspects of our engine if we write it from scratch and by hand. Also, some of the optimization routines in CS make it unsuitable. Paramount to mCode is the graphics. The polycounts of the models we work with are high enough to make the program restrictively demanding.
Any more questions? We're happy to answer them... also, if anyone has any ideas for a new name for the project (replacing "mCode") please post a message!!
Hi again.
Thanks for your answers. They clarified a lot of things to me.
Yes I have some more questions. Hope I'm not annoying (I personally love when people give constructive crticism to me, or even ask questions that may lead me to think of better ways to do things).
You mentioned "very high polygon count" and "demanding" code that need too much hardware horsepower (did I understand it right?).
Question (actually two questions):
a) Why is that? What really make the application you guys develop so unique that it needs to render pictures with better detail/realism than current FPS shooters do with today's hardware?
The images rendered by current top games like Unreal 2, Stalker(http://www.stalker-game.com - gotta see it!), or HalfLife 2 have stunning realism level and very high model detail.
In the same time I did succesfully run Unreal 2 game on Voodoo 3 card (that is thought outdated one theese days) with medium-low rendering quality and at interactive frame rates. This means that even old cards like TNT2 or Voodoo 3 have enough power to achieve acceptable visual quality.
b) Following the first question: what about "scalability", ability of application to *adapt* to lower-end hardware by reducing amount of detail of the content (pictures) that it displays.
---
Actually, I am very interested in your project (partly because it seems that you are really serious about your goals, and I like it).
I run my own project that is close to what you guys try to do (http://realitystrike.sourceforge.net) that I opened about 3-4 month ago, that's why I am so interested.
If you wish, we may exchange ideas and help each other by exchanging ideas and source code.
Thank you again.
Regards,
Track
*corrections - restrictively demanding means that the system requirements will be INCREDIBLY high by current standards (assuming 2.4 GHz is near top-of-the-line). We may use some portions of the CS code later for trivial things, if / when this happens, it will be attributed and credit will be given in credits.cpp / our public info.
Not at all... this is why this forum exists. You're perfectly welcome to ask questions.
To answer your questions, we did not set out to make a "game", nor a "game engine". It did end up being something along those lines, but it must be said that we are not writing the program for the "enjoyment of the end user". If we were writing a game, you would be right to wonder why we are putting so much emphasis on our graphics. We are essentially writing a game engine, but as a a massive tech demo. We are pushing the graphical capabilities on current hardware as far as they'll go, and then some. Why? Because we can. We are trying to recreate reality, how succesful in that only time will tell... but we'll definatley get a very capable engine out of it for anyone's interested work to run on.
One note about older hardware - the graphics card must be able to support OpenGL 1.4 - this is fairly recent, so only newer cards willl work. For now, glide and dx compatibility is not an issue since we don't use them.
I took a look at Stalker, and it is very pretty. It is about our goal for now. That only goes to show, that our project is possible. They are a running the X-ray engine, which as far as I can tell is internal and proprietary... we'd have no means of using it much less anyone else.... you can think of our project as an open-source X-ray or a next generation crystal space.
As for exchanging ideas.... we're kind of in the middle of some major updates right now, but once these are done (the next few days), ill take a look at your engine and we're always open to cooperation with other projects.
-maxx