This member has provided no bio about themself...
Apologies for misunderstanding the topic, I was under the impression (from the description) that this post served to point out, that petros engine can handle larger polygon amounts and you can do whatever you want now.
While the poly part might certainly be true, it is not a representative statement for the capacity or capability of the engine. Tests with the polygon amount alone will not pass as a test for the capacity, therefore your deduction that the "Engine is strong" from the poly count alone is neither complete nor correct. I'd even go so far as to say it is wishful thinking or at the very least a misleading statement.
Let me put it another way: To say just because the polygon count can be increased the engine is capable of a lot more is like saying just because you can add a lot of sand into a glass, the glass is capable of holding large rocks as well.
Though I do agree, "IT CAN SUPPORT NEWER AND MORE CREATIVE IDEAS." sounds a lot better than the precise statement "The engine can handle a large polygon count of a couple hundred millions, if you don't take other GPU- and CPU-based elements into consideration, which will limit the engine long before the poly count" =) I propose you should make a complete guide on what the real limiters are, so that new modders aren't mislead and despair at their creative ideas, which can't be handled by this outdated engine.
And back then I certainly thought polygons were the only limitation. Polygons however aren't a real issue in an engine. They're easy to render (we're talking O(n) time here) and it's easy to do culling and other optimization algorithms on them, essentially reducing the number of polygons that even make it to the render stage. I'd even go so far that the actual amount of polygons rendered is capped and it does not really matter how many polygons you have in theory.
Furthermore, I did NOT test it with a full-fledged particle system back then. Neither did I factor in high detail shadows, high-res textures or the likes. Lastly, EaW/FoC was developed with a 32-bit engine in mind, so there are certain limits anyway. It does not matter that there is a 64-bit patch, the underlying structure in the .exe remains the same.
Therefor I strongly object to your statement that petros engine has an incredible potential and I especially object to the notion, that polygons are the deciding factor in the rendering capabilities.
Why aren't you using mike.nl's manual? He has made the tools and his manual is quite complete, you know?
You can find at this web page all tools created by him and how to install and use them. By the way, it's not a "petroglyph importer", it's a mike.nl-importer ^^
You're correct with what you say. The problem is, that you can't determine a poly limit by testing with an unfinished game (since the result says like nothing), but you can't finish/continue the game before testing, right?
I have solutions for complete systems and I could tell you nearly exactly what we did in UEaW, how many polys we have there/CPU time and what the limits are. Based on that, I could estimate the result when assuming, that there are 10k polys on average more, or less detailled particles and so on. Of course, this would be an estimation with an error rate of ~±10%, but that still would be much better than this one.
Thats your problem - You lack experienced modders, who understand every area of modding and the engine itself, who can tell approximately if your concepts will work in the very end or not. And you won't attract any experienced modders, if you continue with these tests, because they show, that you are more or less blind.
And, before you think this is only hot air boiled into the atmosphere, here an estimation, based on the average poly count I see in your renderers (so an estimation based on an estimation :D): I think you are fine if you add break-offs for the MAIN HPs, the doubled (maybe even trippled) hardpoint amount of vanilla, a 1.5x particle complexity, and the same maximum scale as vanilla with an unit cap of...mhmm...50-75, assuming that fighters are 1 and capitals around 10, while full-scale battle stations are limited to a maximum of 2-3 per map (non/rarely firing stations excluded, they are not very CPU/GPU intensive). But as I said: Thats an estimation based on an estimation, so the error rate is even higher, at around ±30% I would guess.
Ah, btw: shadow meshes requires more computation power than normal meshes, so without a shadow it's even more inaccurately ;)
Sorry to tell you, but your conclusion is plainly wrong. The maximum ship size is not only limited by the maximum poly size. It is possible to aquire for the game a large amount of VRAM and GPU-time, since these two factors have been rising up over the past and there was no 32-bit limitation at all with them. However, it is a totally other thing with both RAM and CPU. RAM is in a 32-bit program limited to ~2GB (no, the 64-bit patch doesn't fix that), means the amount of scripts and total models, which are different, are limited. The worst thing is the CPU. It doesn't even get the CPU to coughing, when computing 222 non-moving, non-firing objects. It's a totally different story, when it comes to fighters, particles and firing. The CPU needs to compute every shot (hit/miss/which target to aquire?), every movement (e.g. of 200 fighters) and every particle. The first two things even when they happen off-screen. Since FoC is only a single-core application (32-bit XP developed), with 2,20GHz and a sandy bridge you would NEVER EVER be able in a realistic simulation to even render half that amount of polys, with full 30FPS.
Models don't start usually lagging, just because they have a lot of polys, the engine can handle them just as if they would be separated in a dozen models or something (can handle them even better, since they are no different AI entities). However, the engine will get problems if you try to scale a high-poly model. The required computation power of a scaled model grows exponentially with the poly size and linear with the scale factor. As far as I've found out. This applies especially if there are 2 different big meshes (shadow+hull). While it was totally okay to have 4 ISDs with a total of 100k polys and a scale factor of 1.2x (can't remember at all the exact scale factor), it was impossible to render 2 lucrehulks (total 70k polys) with a scale factor of 4.x without lag. So I would suggest to test high poly models with different scales too.
On another note: Only the polys visible on screen count to the poly count.
My experience (yes, thats confirmed and tested on 3 separate systems)
Hardware: CPUx2 ~3GHz, ~1GB VRAM: 2kk polys per image, 300-500 units (including single fighters) per battle
=>Petroglyphs engine is primary a single core engine, so more than 2 cores (one for the rest of the system, one for the game) is unnecessary. AI control of fighters is very expensive, so thats the true limitation of the engine.
=>Polys are also including the particles, with every particle in the particle system counting as one poly. Which leaves in a full scale battle, when half of the HPs are destroyed around half/a quarter for the models.
=>results in approx. 20-30FPS, which can already be counted as "lag"
Count that as returning a favour...Ignore it, or use it, idc
Thats your fault, not ours. It's a secured https-connection with a SVN running on the port, so it's very likely that your virus scanner will "detect" something.
-.- We have announced over the past 3 years again and again that V1 will be SPACEONLY.
Yep we did. But nevertheless, remember to put the ramfix also into the FoC-data folder, sometimes FoC doesn't like you and wants to have it twice :P
Vermutlich nicht...überprüfe ob der Ordner im FoC-Mods Ordner ist, ob die Mastertextfiles im Ordner \Data\Text vorhanden sind und größer als 0 kb sind und ja...wenns dann nicht geht, kann ich dir auch nicht mehr weiterhelfen, dann fehlt irgendwas an deiner FoC-Installation.
Are you sure you have run the Launch.bat? This should build the mastertextfile at runtime. Try to use Build.bat and check, if a textfile appeared.
Unfortunately not, he has made one song for us and left afterwards.
The news also say to run Launch.bat...this builds the mastertextfile at runtime...2 of the factions aren't playable, there was a strange bug with that last revision, it killed the GUI layout and parts of the faction system, probably something accidently reverted some files to an older revision.
You have to accept the certificate once. If you check the adress, it's a https, so the secured connection is necessary (and with that, the certificate too).
Nope, this version is primary meant for developers, because it is unfinished. Through that, we think SVN is enough.
You're very welcome, if you have high-level coding skills ;)
Nah, it wasn't chris leaving which stopped the project. It started a bit earlier with a stop of the modelling department, when evilbob left...I was working on coding for another year, so I've stopped working on this mod effectivly a 3/4 year after chris had left. Tbh, chris presence was preventing progress, since he was still the leader, yet quite inactive and I was not sure how to continue.
Actually, the vong are also already deep in the story of SW. References in KOTOR (earliest reference in SW-timeline), another reference in the rogue planet series, Thrawn trilogy, the expedition thingy in republic times, a ton of hints in new-republic time things...truly, if you consider one of the SW-books as canon, you have to consider the vong also as canon, since they can't be seperated from each other. They're not interfering (so uncanon), they are completing the stories! (at least to my mind ;))
Well, at least they are not interfering with film content (which is A-canon and has the highest value) like TCW-series are. What we have to admit is, that we are using a lot of fanon and uncanon designs, but you can't work with these few comic (which have also a less canon-value btw) or book cover images. However, the story is made in general lines by G. Lucas himself, if I remember correctly and is written by the most famous SW-authors. So if you consider e.g. the X-Wing novels as canon, you can consider the vong as canon as well...just not as...normal...as other SW-books. But that doesn't mean uncanon ^^
We are going to follow the NJO-story as close as possible and you will be surprised what we have planned for the future...
Plus it is not a minor illegal act of reverse-engineering the .exe, there were some cases in the USA, where fines of more than 5000US$ were imposed. And we wouldn't be accused only by moddb, we would be accused by Petroglyph/LucasArts (think LucasArts, they were the publishers).
Well, I think humans would ask them to grant interest rates on their working hours and a pension, based on working hours (as well as payment=>the more you work, the more you get + inheritance and work hour transfer to other accounts) and if granted, they will not rebel in any way, no. If not granted....uh. Messy war. Somethin' like that. Maybe even a formal protest, triplicated. Don't know.
Well, usually you are saying that EaW/FoC engine is capable of rendering up to 1kk-1,5kk polys per image (high end PC). If you have a super (high unit cap, replacing a lot of smaller units) with a high poly count, that doesn't hurt too much....A frigate with high poly count would be MUCH worse. Or a bomber with 21k polys (yeah I've seen that...don't ask...). So this model is fine.
I am the supreme overlord, I can foresee future events...You shall be enlightened soon enough too, infidel! ;)
Thats not a very good idea, remember, there are going to be super capitals as well, so they wouldn't even fit the whole map. If you want to see the fighters, zoom in :P
Concerning fire rates: Batteries will actually have a short delay in their shots, but a high cooldown time after one salvo of maybe 12 or more shots.
Have you ever tried "scripting"? ^^
In fact, there are only a few high-level scripters and I don't know a mod where these scripts have been used...RaW maybe, but they have reduced scripts as far as possible too. There were a load of scripts at AB, but not used in any mod (for example an influence script, where a planets stability is calculated, with factors like buildings, units and nearby planets. When this value is decreasing to much, revolts can become possible).
Oh it is. It does have a third dimension, like any object which exists. You just can't catch the third dimension in an image ;)
And a very flat OBJECT has still a third dimension, otherwise it's not a real object. 2D are only abstract versions of our life.
Yeah you're right, pictures are usually 2D...though, I have a 3D-monitor, but I'm not using it. Additionally, we haven't prepared a 3D-2nd layer picture, so there won't be any 3D-effect even if you have a 3D-compatible monitor. Sorry, our fault.
If you are referring to the flatness: If I see it correctly, this ship is even a bit thicker than the ones in the source .
It's done when it's done ;)