Strange flickering effect when I bring a dif near to terrain

#1 Can you get a screenshot of the issue?

#2 Wow. I was checking this thread before retiring for the evening, and saw your post. If you're working at this time on a friday night, I'm answering you _now_ . :-) No fear, I don't expect you to respond further tonight--I've been reading a lot of GG forums lately, I know how thin you're spread--I hope you have help in your job.

Anyway: no. I tried to get screenshots to no avail. Finally I figured out a hi-tech method of showing this--hope you take mpeg (kino crashes when I try to export to AVI):

http://cm4msaa7.com/flicker.mpeg

3.5 MB

I've been trying to isolate the problem, and I'm pretty sure I've found some helpful information:

1. It happens after rotating and scaling either the dif or the heightfield in the mission editor for a while.

2. If it happens after doing moving/rotating things and then I save the mission, it will happen immediately upon starting up the mission again in a new TSE instance.

3. (and this is a big one): While making this video, I was just leaving it there flickering for quite a while while I filmed it. After turning the camera off, I went to end the mission, I got a BSOD/reboot. I didn't have time to read the error message, but five'll get you ten it was from the video driver. (I did actually upgrade to the very latest and greatest. It MAY take a little longer to start flickering with that).

Other things I can tell you, I had the terrain scaled at 1 1 1.5 and it happened, and in the image it is way down to .1 .1 .15. It doesn't seem to happen if there is no texture on the terrain. With two difs I didn't seem to have the problem, just with the terrain.

That's all I think I know.

Lee

#3 Hmm - that looks a lot like intermittent corruption of geometry. At a guess I'd say that it might be your card crapping out on you. :-/

You could test by finding someone with similar card & drivers and giving them your game/executable to run.

It could be a bug in TSE - but since you're using Atlas it's unlikely (Atlas doesn't change geometry once it's been uploaded to the card - if it was legacy terrain you could be seeing a glitch in the terrain renderer code).

What happens if you, say, put Doom3 on at high detail for a while, or another high-end 3d game?

#4 Oh yes... definitely a video card dying :)

#5 Well, I obediently loaded Doom3 back up and played for about an hour with highest detail and resolution--no problems.

I started wondering if it was because I was running in a window. Interestingly, Doom3 crashed on me after a while when running in a window.

Then I fired up TSE Mission Editor in fullscreen...and so far...everything appears to be fine.

I'll try the binaries on another machine if it happens again to be in fullscreen.

I appreciate your help!

Lee

#6 Nope, no joy. Interestingly, it was when I bumped up the view distance (as per your helpful suggestion in another thread) that the flickering started back up, fullscreen and all.

The Doom3 crash in windowed mode makes me wonder, anyway. I've got an ATI card I'll stick in tomorrow and see what happens.

#7 What is your view distance set to?

#8 I've had it set in a range from 500 to 5000 where it happens. I'm going for a small person in a giant world type effect.

#9 5000 is quite much.

#10 Indeed. However, the flickering effect happened at 500 as well. I'd be happy to send some resource files to reproduce if desired.

I may not need 5000, but I will need it pretty big.

#11 Ok! It doesn't seem to be happening on the ATI x1300 card. So I'm convinced--thanks yall for your help.

Doesn't perform well though. Maybe it needs to be tweaked.

#12 X1300 series cards are SEVERELY underpowered. I've seen them draw a couple hundred cubes with optimal render command submission, and if you maximized the window it would go down to maybe ten FPS... bring the window down in size and it'd go up to 300+ FPS.

These were untextured, non-shaderized cubes.

The best tweak to do for a 300 series is to turn all your rendering options down as far as they'll go. ;)

(To add - my 9600 mobile card in my laptop routinely outperforms X300's, and possibly X1300's as well, by a wide a margin.)

#13 Thanks for the tip on that. I bought it almost at random some time ago for another purpose, pretty much as an ATI test card or something on that order.

Got an nvidia 7600 gs and it works fine and so far does not have the flickering issue. So! The guru(s) are right. :-) I'm sure I'll be having to do a big upgrade at some point just to run the game I'm planning on making, but I'll put it off as long as I can.

Speaking of which--I've got what I think is an interesting question for you, Ben, if you care to answer it. What types of performance improvements should one expect in a TGE or TSE built on a (native) 64-bit platform? Ie. Vista, OS X, or Linux? My feeling is that no one seems to aware of what kinds of things that will enable in gaming technology. Is it just a matter of lots more objects? More complex scenes? Deeper scenes? The fact is, it seems to me, that without a 64 bit consumer-level Windows OS, developers have not really been trying to take advantage of all that extra computing bandwith....?

Thanks again for your help!!!!

Lee

#14 From the perspective of game dev, 64 bit represents an upgrade to the processing infrastructure that gives more available memory and some faster CPU primitives. It's not really that big of a deal - what you can do on a high end 32 bit CPU and a 64 bit CPU isn't that different.

It's mostly just a headache as you have to ensure that your data manipulation is 64 bit safe, conform to the associated OS and API changes, and so forth.

It's sort of like Unicode - for some things it's a HUGE deal, but for mainline game dev it's just a bump in the road. (ie, "Got unicode?" "Yup." "Great, let's move on to something more interesting.")

Honestly - most people aren't pushing close to 100% of what current hardware can do, so I'm not really convinced that giving them more of the same is really going to revolutionize anything. Consider a physics SDK - they have value because they give you more out of the same resources than what you'd be able to implement yourself (presumably).

Or something like Granny - it gets more mileage out of comparable resources than what you'd be able to, probably.

So having a few hundred terabytes of addressable space is great but what does it get you? Does it make it easier to produce art? Does it make the game more fun? Does it enable something we couldn't do before?

Not really. It lets us play fast and loose with memory (oh boy!) and sidestep some silliness with how we assign memory ranges, but it doesn't really make it any easier to make, say, GTA. And for smaller, non-epic-scale games like Marble Blast - not much change at all.

Oh wait, the XBox 360 is 64 bit, isn't it? But all the wins are because it has good connectivity, good graphics hardware, and multiple powerful processing elements. Honestly, I don't think we spent any time at all dealing with 64 bit related issues when we ported Torque to it, and subsequently developed MBU on it.

64 bit is great as it seems to be an opportunity to break with some older standards (which is good), and it carries with it a bunch of general upgrades to the OS and hardware, but in and of itself it's a pretty minor and unexciting change - if you wanted 64 bit arithmetic, most chips have supported that for the last few generations, and not a lot of applications need more than 4gb of addressable memory.

So... yeah - it's a road bump, not a huge thing, and although it'll eventually allow us to probably do some interesting things, I don't think you're gonna see it revolutionizing anything about games, except maybe according to AMD/Intel/IBM marketing material. :)

#15 Interesting. Thanks for that. I've been looking for informed opinions on the subject.

I am encouraged that you think, as I do, that the current hardware limitations have not yet been fully exploited. To my (35 year old) perception, there has been an explosion of processing power in the last 6-8 years, in both cpu's and gpu's. I have not seen a corresponding explosion in game related graphics capability. Not really. In 1996 I saw real-time 3-d rendering done on a Commodore 64. So I reckon it will take circa 15 years to fully take advantage of the current hardware.

HOWEVER, there are two tidbits that have caught my attention. First, you mention the larger addressable RAM issue. I'm finding that what I'm doing with TSE is using a lot of RAM, and I've only gotten started. Personally, I'm of the philosophy that it is best to develop games for the high end. I can easily see my game requiring more than 4 gigs of ram. And I am comfortable with that. I had not considered that singular issue.

Secondly, there is the polymesh collision thing. Currently I am essentially converting some models into heightmaps to take advantage of Atlas. I need this for my game concept--it's simply essential. I need terrains that look like certain real-life models. But you mentioned no pipeline improvements coming with 64 bit processing. Well, if I can go through RAM like a Bangkok, erm, lady of the evening, doing a little polysoup collision as the legend has it you guys have up your sleeve right now, well, that would speed up the pipeline quite a bit!

#16 But polysoup isn't an issue as regards memory usage - the polysoup lookup stuff is tiny, and very comparable to the lookup stuff we already have around, say, convex hulls. It's performant, too. Mostly is an issue is how people view collision techniques and how our art pipeline is built - not whether we can address more RAM or not.

Typically, 90% of a game's size is art assets. And a standard video card is only 512mb, estimating liberally, for the foreseeable future. Maybe in a few years we'll have gigabyte cards as a reasonable consumer expectation. But if you've only got that much space, what are you gonna fill your extra 3gb of working space with? If you're paging stuff to card, you may as well page it from disk as well - means you can run on a lot more systems. If you're running a simulation that takes several gigs of data, you'll likely find it difficult to run that simulation at sufficient frequency to be interactive along with high end graphics, physics, and effects.

Even the biggest scale current gen games (big MMOs, or GTA style games) have very modest simulation requirements, or else offload calculations to auxiliary servers. They expend the vast majority of their effort on scalability - NOT on depth of simulation. I bet if you compare the vehicle physics in GTA:SA with the vehicle physics in the first 3d GTA, you'd find they burn the same amount of CPU on it - just do things more efficiently and with better tuned values.

I'd look at the variation of game quality on the PS2 to get an idea of what's possible with current and previous gen PCs. Compare the relatively primitive launch titles with end-of-life games like Shadow Of The Colossus that meet or exceed quality of play and visuals even on platforms like the 360.

Most of the high RAM usage people experience in TSE is due to one thing - textures. And if it's not that, it's often because they're using subsystems in ways that end up wasting a lot of memory. A properly built game should be very, very tight with memory - and every game we've shipped has ended up getting a lot of time spent on its resource consumption. A few simple mistakes can result in hundreds of megs of memory being wasted. This applies to C# as well as C++ and other languages - I think we've spent more time thinking about memory usage on TorqueX than on any other single technical issue.

As it happens, Atlas is a paged polysoup model system. There just aren't any tools to bring in non-heightfield data (we're working on 'em! :). But check over the runtime - everything you need is there to bring in, say, a million polygon model of a stadium and render & collide with it properly, if only the tools were ready.

So I think in the end it comes down to quality of implementation and paying close attention to how you expend resources - which isn't really anything new, but it's easy to lose sight of it in the face of exciting new stuff like 64 bit or PCX or multicore chips or what have you.

#17 Great post Ben--as is almost always the case in software development--it's easy to "fill up" all your resource capability, but it's hard to really even think about how to best use what you have, instead of simply -using- it.

I still remember writing 30 page papers on a 48k word processor on an Apple ][+ in high school--and while we can certainly do more with word processors now, I'm not so sure that we do it more efficiently, software wise.

#18 Very illuminating--thanks! I think I learned something. You're certainly right about the textures being responsible for my big memory usage.

So...I guess I'll just go back to whining about wanting tools to bring in collidable meshes! hehehe. But seriously, I want it now. :-) You're a tease..."oh it's IN there...you just can't easily USE it".

Actually, playing with Atlas is really grand fun, and I think it will serve very well for now.

Thanks again for the small treatise. It was actually quite helpful for someone like me to set his expectations realistically. Very helpful.

#19 Delete the dupes! :)

#20 I did once already...it has a way of not "sticking" on the gg boards. i'll do it again..