Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Martinus on July 13, 2003, 09:35:16 am
-
[color=66ff00]Although it has been mentioned before I was wondering if anything could be done to fix the clipping problems in the game?
My main reason for requesting this fix is that our models are becoming increasingly complex, clipping results in less realism and compromises on model geometry having to be made. For a good example of this take a look at Venom's atmospheric experimentations, the thrusters show quite clearly through what should be opaque geometry.
Does anyone have any thoughts on the feasability of this?
Thanks. :)
[/color]
-
fs2 since day one has always had clipping issues, i think fs1 didnt have it as bad, but fs2 is plaged with clipping. this is something that should be looked in to, but im asuming no engine updates until the work out the current beta bugs (if any).
but yes a updated model fixing to clipping should be what the game needs to fix the whole engine up. also, is it possible to make the models solid so that the camera nor ships could possibly penetrate (usually faster then 20/MS cap-ships penetrate the model and fly thru each other)?
-
[color=66ff00]Is anyone willing to look into this? It's got quite a lot of attention but no replies i.e. it's either not possible or it's quite a popular idea only...
[/color]
-
I found that when doing my HT&L stuff that I had problems with clipping. Turned out it was because the near plane was too close the camera.
Not sure if the same solution would work for the 2D engine FS current uses
-
Well, that remains my main request for an engine upgrade. The damn clipping ruins all my attempts at doing something better than what I usually do. I have lots of cool ideas, trust me, but every time, it's the same thing: it looks crap ingame.
-
it's my main request too.
I don't know if it is related to zbuffer, as many others said, what I know is that whenever there is any barely ambiguous situation, the engine generate weird clippings.
The mother of all the ambiguous situations is obviously when there are intercepting polys, but it generate similar clippings in many other situations that should be safe, expecially when there are convex shapes, like engine inlets or when there are small details over bigger faces.
With inlets, the clipping is worse when the internal and the external faces are close to each other: knowing this it is possible to reduce the effect, but not to completely avoid it, and often it also mean to reduce the quality of the model and spend ages adjusting the mesh. If needed, I can provide a clear example of how scaling up the mesh (and therefore increasing the distances of internal and external faces of inlets) reduce the clipping problems
-
A couple more things: those problem disappear when you play in glide mode (but obviously there aren't many voodoo owners), never tested in opengl
Those problems also happen often at the junction between the subobjects, and considering that the polylimit per subobjects is pretty low, this is an additional limitation we have in building more complex models
-
There may be a point at which we can't make some things better.
And as RT pointed out, some advanced tech "solves" the problem, but that will be at the expense of the system requirements, which is something people scream about when we want o make them updated as of 3-4 year old tech ;)
Let's see some SPECIFIC screenshots and their accompanianing models, maybe there is somethign we can do about this. That does mean that you will have to provide the model so that the coders can test it, provided anyone picks up the banner.
-
Come on, there's countless pofs with that pb, don't even1 need to d/l anything, many default FS2 pof have clipping issues.
There may be a point at which we can't make some things better.
There's some stuff that MUST be adressed, too. If the most annoying graphical problem from this game can't be corrected, and as my main occupation is to make cool looking things for FS2, I see no point for me to continue modding it. Take any stupid FPS, none suffers from clipping like that, and they're full of intersecting polys and weird geometries.
-
[color=66ff00]This is primarily a Freespace upgrade request, the minimum requirements for the mod are going to be higher than vanilla FS2.
I'm sure it would benefit all modders in any case.
[/color]
-
This is what I keep saying, the basic problems with the retail FS2 ought to be fix0red before fancy stuff is implemented. What good's your HT&L going to do in a game plagued by god-awful clipping?
-
Originally posted by diamondgeezer
This is what I keep saying, the basic problems with the retail FS2 ought to be fix0red before fancy stuff is implemented. What good's your HT&L going to do in a game plagued by god-awful clipping?
:nod:
-
if you need some test pofs i can give to you my awing, in different sizes:)
-
[color=66ff00]Is this the kind of thing that people are not interested in, or is it a case of not knowing how to fix the problem?
[/color]
-
Originally posted by RandomTiger
Not sure if the same solution would work for the 2D engine FS current uses
I think it's an issue of not knowing, and people are doing other stuff right now.
-
[color=66ff00]3.6 is released when all the current bugs are ironed out yes?
If so I guess we'll have to wait for at least 3.7 to see the graphics glitches fixed. Oh well, patience Daniel son....
[/color]
-
I'd like higher-polycount abilities, and ships that can dissapear with a holographic-like fizzle ( a part of my storyline).
-
Originally posted by Unknown Target
I'd like higher-polycount abilities, and ships that can dissapear with a holographic-like fizzle ( a part of my storyline).
http://www.hard-light.net/forums/index.php/topic,15935.msg306770.html#msg306770
-
Don't mean like that, I mean they fizzle out.
They're actual holograms, not cloaking :D
-
So cloak them then use ship-vanish. Any reason why that wouldn't work?
-
Well, I just wanted a bit more eye candy than them simply dissapearing. Maybe like grid lines go across the whole ship, then it fades away.
-
Originally posted by Unknown Target
Well, I just wanted a bit more eye candy than them simply dissapearing. Maybe like grid lines go across the whole ship, then it fades away.
I don't know if you can do it but animated cloaking textures should do that for you.
-
animated cloak textures arent supported yet.
-
Originally posted by Inquisitor
There may be a point at which we can't make some things better.
And as RT pointed out, some advanced tech "solves" the problem, but that will be at the expense of the system requirements, which is something people scream about when we want o make them updated as of 3-4 year old tech ;)
Let's see some SPECIFIC screenshots and their accompanianing models, maybe there is somethign we can do about this. That does mean that you will have to provide the model so that the coders can test it, provided anyone picks up the banner.
Perhaps there should be a point where we have to say...if we want to take this project any further...having something better than a P200, 16mb video card, and 64mb of RAM is going to be required.
Everyone these days is upgrading for Half Life 2 and Doom III. Their bare bare bare minimums are a GeForce card of some type and a Pentium III. Now I upgrade probably once every 3-4 years...so I UNDERSTAND...but 3-4 years ago was a PIII 700 with 32mb or 64mb of video memory if you were a gamer then...the original specs for FS2 were for a computer some 6 years ago now.
Venom's earlier model for the GTF Ezechiel had heavy clipping. That'd be a good one to work with.
-
Icefire's right. We're getting to a point in the upgrade cycle that we simply have to move past the old system requirements. Otherwise, if we stay at the same minimum requirements, then we will never be able to truly implement all the stuff we want to.
-
Originally posted by PhReAk
animated cloak textures arent supported yet.
Animated cloaking has been supported since several months before your feature, actually - just use the change-model sexp in conjunction with a model with animated textures.
-
it doesn't animate at this stage, which may be problematic, since its like its own glowmap (not effected by lighting):
(http://www.swooh.com/peon/phreak/cloak2.jpg)
not to mention that the effect doesn't get less visible with distance:
(http://www.swooh.com/peon/phreak/bright_cloak.jpg)
(http://www.swooh.com/peon/phreak/dark_cloak.jpg)
-
could you please talk about that in the thread that, afaik, already exists, and deals with that matter?
Here I want the damn clipping removed, taht's the only thing I want from the SCP, and w/o that, I won't mod anything anymore, since I want to push FS2 limits. simple equation here: bad clipping= same old models= no interest in doing anything else, to me.
-
should be fixed with HT&L
-
what about Fighter beam is that ready?
-
some better engine effects than the old, blocky ones, would be nice...
And aren't animated textures already implemented before the SCP? I mean, look at the engines, they have animated textures.
-
Originally posted by PhReAk
should be fixed with HT&L
really? well this is a good news
btw, I can't believe that there isn't much to do to fix this problem w/o killing performances: considering the games of the same period, fs2 is one of the games with the most weird clippings
-
Hold on... Phreak, you mean to tell us that 'simply' by implementing HT&L you will knock the clipping thing on the head?
-
somehow I doubt it :doubt:
-
I don't doubt that the problems with clipping are due to the fact that the FS2 game enviroment is expansive. You can't expect a 16-bit Z-buffer to be accurate when the Z-range is between, say, 5 and 60000 units. Of course, the Z-buffer is much more accurate with near objects than with far ones (because, Z-buffer accuracy is not linear, unlike a W-buffer), but I can see plenty of problems if an object is in a medium range, yet is large enough to have details visible from that range
-
any reason why a 24-bit z-buffer wouldn't work then? (other than i don't know how to test if one exists)
-
Fry Day, our problems with objects at medium and long distances objects are really minor compared to those at close distances.
The only problem at long distance I know of is, as reported by venom from his ground experiments, when you have huge faces with "small" details on them(causing the small details to disappear).
At closer distances you can notice it more, even if zbuffer works better, and you notice it expecially whenever there are groups of faces one behind the other at close distance, usually in convex shapes (intakes and other similar situations). This is a big problem for modeller: you can easily avoid or reduce those problematic areas in very low poly ships, but if you want to increase the detail, and the beauty of your artwork, well this is a very big limit.
Personally I don't see too whay we should spend time creating new models for an engine, if this engine doesn't let us build models nearly comparable to actual standards.
And althought my knowledge is limited, considering the 3d games released about in the same period, well I think that fs2 is the one with more clipping/zbuffer problems I saw, so excuse me but I don't think that it is only a problem of 16bit/24bit zbuffer
-
PhReAk has receantly made some terribly inspiring progress with his OGl builf in terms of clipping.
BTW I had an idea for the reason of the clipping when reading the transparent texture thread.
I's a wild guess, but I have a gut feeling that the order of polys being rendered is a key feature behind the weird clipping of FS.
Of course this could be old news, but I'm no coder, so please forgive me.
-
im figuring that the girders in that picture use the "pure green is transparent" method of transparency. if a transparent pixel is in front of a non-transparent one, then it would turn clear. since the models already draw back-to-front, we may just need to implement tga maps w/ alpha channels
-
The problem is not with a single model, but rather when you have several models one behind another...
About the 24-bit Z-buffer, you could request one in the pixel format descriptor in OpenGL, when running in 32-bit mode, but I don't know about DirectX... I personally think that it's the crux of the problem, therefore, should be given a try.
-
quick search of msdn
typedef struct _DDPIXELFORMAT {
DWORD dwSize;
DWORD dwFlags;
DWORD dwFourCC;
union {
DWORD dwRGBBitCount;
DWORD dwYUVBitCount;
[b] DWORD dwZBufferBitDepth;[/b]
DWORD dwAlphaBitDepth;
DWORD dwLuminanceBitCount;
DWORD dwBumpBitCount;
DWORD dwPrivateFormatBitCount;
} ;
union {
DWORD dwRBitMask;
DWORD dwYBitMask;
DWORD dwStencilBitDepth;
DWORD dwLuminanceBitMask;
DWORD dwBumpDuBitMask;
DWORD dwOperations;
} ;
union {
DWORD dwGBitMask;
DWORD dwUBitMask;
DWORD dwZBitMask;
DWORD dwBumpDvBitMask;
struct {
WORD wFlipMSTypes;
WORD wBltMSTypes;
} MultiSampleCaps;
} ;
union {
DWORD dwBBitMask;
DWORD dwVBitMask;
DWORD dwStencilBitMask;
DWORD dwBumpLuminanceBitMask;
} ;
union {
DWORD dwRGBAlphaBitMask;
DWORD dwYUVAlphaBitMask;
DWORD dwLuminanceAlphaBitMask;
DWORD dwRGBZBitMask;
DWORD dwYUVZBitMask;
} ;
} DDPIXELFORMAT, FAR* LPDDPIXELFORMAT;
im no dx coder, but it looks rather convincing
-
Originally posted by Fry_Day
The problem is not with a single model, but rather when you have several models one behind another...
the transparent green hide"s only the polys from the same subobject ( say you have a turret behind a grider, the turret will show dfine, so will a fighter flying behind it ).
-
like was said in OpenGL most zbuffer problems origionate from faulty calls to gluPerspective a good example of some of my code is this
gluPerspective( 85.0f, float(Get2DResX())/float(Get2DResY()), 0.001f, 10000000.0f );
but it also has to do with your video card - i've got this cranked really close for the ZClip because my video card can handle it, but a publish build will have 0.1 - even the GeForce FX has huge clipping problems with that call of mine, when my Radeon 7500 does not - but 0.0001 it gets clippy, at 0.00001 it freaks
-
The difference between a near Z of 0.01 and 0.001 is huge. I'm betting you can even get away with a near Z of about 1, without visible differences, and it'll help a lot.