If you’re reloading the game (after a previous save), a hard-load operation is expected. Since the data isn’t there already, you pop up a “Loading…” screen and load it. There is no problem, and you don’t need to force the player into specific locations to save.
my point is simply that for 1 million triangles on screen, unless there is some development in disk technology i’m unaware of, some serious ‘hard’ load times are going to be in order. personally if i have to look at a loading screen for more than 10 seconds, i’m bothered… i’d just assume do something else while its loading… it breaks peoples lives up into little un retrievable chunks, kind of like commuting and commercial tv. i don’t play too many video games, if any by any measurable standard. but the ones i do have, have rediculous loading procedures, which are generally unecesarry, like reloading the environment you were just in for a replay or something. i would probably play more often if not for that. the load times these days are just rediculous, but if people are accustomed to it, i guess they get what they ask for.
No, the primary performance difference between them is that static LOD gives the card the data as it wants it (large, contiguous streams), while the continuous LOD scheme is unable to do so.
The static scheme is not streaming data up to the card very often; maybe once every 5 seconds at maximum player speed. Not only is this eventuality rare, it also happens as the card would prefer: long, continuous streams of data. This is benifitial for the CPU and the GPU.
The continuous scheme has to frequently update the data, possibly in large quantities, but possibly in small portions. In either case, it hurts more on the CPU and the GPU side.
just curious if uploading data halts the cpu in current implimentations if the app is not multi-threaded? this is something i don’t know much about. and just for the record the algorithm discussed here only uploads continuously, but large has yet to be seen. the thing that scares me about large uploads, isn’t the uploading. its where to get all of the data to upload. for a nurbs surface for instance, all of the vertices must be procedurally generated, but reading from disk is not much better right now with cpu trends versus disk io. any LOD algorithm which utilizes ‘mipmapping’ to generate displaced geometry must recompute the mesh for each level, or risk non-representative sampling by not utilizing mipmapping, which would mean more visual popping in the LOD. so i have to ask if we are talking about stream non-continuous LOD here, or just streaming in a static mesh with no LOD in chunks?
I’m not sure you understand the impossibility of what you’re considering. There is no one-size-fits-all approach. The reason codebases are “built to be disposable” is because constant hardware changes and competition requires it. You can’t predict the future, and everyone who has tried to in this industry has been burned by it. People who thought that non-programmatic hardware was the future built engines around that, and these engines needed almost total rewrites because the future didn’t turn out as they hoped.
there are reasonable ways to go about providing hardware hooks without throwing the baby out with the bath water… assuming the baby is worth keeping at all in the first place. producing low quality systems has just become habitual. its a waste of energy… but i can understand why it has flurished, because building high quality systems is hard to coordinate with large teams, especially large teams who do not actually rely on the applications they develope – though that is less of a problem in the video game industry i figure.
The needs of an RTS game are not the needs of an FPS game; indeed, their needs in terms of terrain, field-of-vision, and all manor of other things are very different. They have some basic needs in common (they draw meshes if it is a 3D RTS, etc), but there are plenty of needs that they do not have in common, and those games have little in common with something like GTA or Zelda. As such, running one kind of game on the engine of another, while possible, is not terribly wise. You will never make a generalized engine that can run any kind of game in any kind of genre nearly as well as you can if you made a specialized system.
yeah of course, different systems would be used for a typical top down RTS versus a first person type configuration… same as say a largely 2D verus a 3D configuration. the trick is just to paint as wide a swatch as possible as far as abstraction is concerned, without introducing overburdening dependancies.
More importantly, the present exists. If I knew for a fact that programmability on GPUs was coming in 2 years, would I build my engine for a game that was coming out in 1.5 years with programmability in mind? Of course not;
no you’d be wise to leave hardware to hardware and software to software. that is keep the two seperate dependancy wise. i would personally never build hardware into a system directly. you are right though that graphics hardware 2 or 4 years ago was a very chaotic affair. i think it is fairly well stabilizing though to the point that its behavior can be fairly well predicted and abstracted with the introduction of the programmable gpu… in my experience 64bit processing allows for a much more advantageous environment for recoverable development than 32bit really allowed for… though i believe it could’ve and should’ve been done with 32bit. the window is very wide for 64bit though… and the restrictions of 32bits on matters such as run-time programming (lisp), precision, and addressing will not be present with 64bits. and i don’t expect 128bit processing anytime soon… i think there is a noticible curve going from the amount of time to transission from 8 to 16 to 32 to 64 bits, which probably correlate with the order of magnitude of the values achievable by such alignments. in other words, developments are becoming increasingly stabilized in the big picture.
it makes no sense. It serves no purpose to the present; the needs of a progammability-aware engine are not the same as one that isn’t. The purpose in building such a system for a non-programmability-aware GPU makes no sense, and can even make it more difficult to get that game out in time. The future isn’t here yet, so there’s no need to go to drastic lengths to plan for it.
if you can save time on the next iteration it is worth while… especially if you invested in the last cycle… and i’m sure this is done to a degree.
That’s not to say that you should write rediculously short-seighted code either. Flexibility can be built into systems without going too far. Programmer prefer to build flexible systems that can be “easily” replaced by others if they no longer are appropriate for the new task. This does not mean building a gigantic monolithic system that does everything.
yeah i agree… now is a good time i think to start shifting in this direction. as the days pass by, this approach becomes more and more reasonable. the trick is just being able to recognize and admit that the old ways are counter productive when the times come and the environments change.
the real trick with monolithic systems though i think is, throwing more people at them does no good. so you need a sort of ‘heroic’ programmer or two who can think with the same mind to pull it off, or at least get it started.
Maybe someday ROAM and other similar algorithms will be the right way to go. Maybe you even do ROAM-type stuff on the GPU completely.
i suspect it will go completely on hardware. the question i think isn’t a matter of ‘if’, but ‘when’. would work well probably with the regular mesh images advocated by ‘hoppe’, and nurbs parameters. but in the mean time i don’t believe it is inefficient to pull off with contemporary hardware capacities… just takes a lot more thought to impliment.
In which case, all your work will have meaning. However, for today, it is the slower path. For today, it has only limitted applications, and few of them are high-performance. For today, there are better alternatives. And if we ignore today just because we believe that things will be different tomorrow, we lose out to those who are living in the present rather than the future.
i’m not advocating anything… the results will speak for themselves if i have anything to say for it. the only strong counter argument i see is this whole batching thing which proports that a single glDrawElements dispatch sent across agp memory is as fast as drawing 1000 simple triangles. first of all this breaks down when your shaders have enough instructions… notice how coarse the geometry is with modern games. but even for simple shaders, i have a feeling utilizing displaylists will totally rip the performance hit out of that batch argument. if you have doubts about the cpu overhead for my ROAM algorithm, i have a feeling they are unfounded, because the cpu overhead is nothing.
Just because there’s a cliff 1 mile in front of you doesn’t mean you turn; you still have 5,279 feet before that cliff becomes an issue.
this depends on just how fast you age going 
for my own needs, i’m going very fast… or if you don’t like the ‘fast’ analogy… then lets just say my reaction time is very slowwww.
I don’t know what that means. Bigger, better geometry means more (re: quantity) of geometry. Clearly, the size of a trangle has no impact on how long it takes in terms of vertex processing, so the performance benifit of using static schemes is in having more triangles.
yeah, i was just commenting, that just due to the bus versus the rasterization hardware… current trends favor an environment with a few large high resolution objects… versus even a lot of small high resolution objects. say we can’t have 1000 rocks rolling down a ravine, we have to have a single boulder. i’m not saying that is anyone’s fault necesarrilly, just unfortunate. however if people grow too accustomed to this thinking, they might pass up an opertunity to improve the bus while focusing too much on the rasterizer. tunnel vision or something.
With that kind of logic, we’d still be back in GeForce 1-levels of performance.
You have to optimize, and you optimize where it counts. And if it means that large strings of triangles are the optimal path, so be it; at least we have some path that is optimal. The fact that it happens to be brute force (the path that hardware tends to favor) only makes it easier to use.
yeah i agree, that any improvement is improvement… but if resources are just being focused along one path versus another, i think the aproach is lop sided. and only favors competitive mediocrity.
