Trees in BS.

[Haegar]

As long as I'll be able to switch it off, and everyone without the latest FX-62, Conroe quadriple core CPUs or whatever, will agree. No point in having solid trees if you get 8 fps.

 

Hm, well, but at a certain point you have to make a cut. Or in other words: you can't expect every future addon or programm runing on your old gear.

 

Beside this: for my feeling 20 fps in a town is a very good rate and absolutly playable. So be happy!

[Force_Feedback]

Hm, well, but at a certain point you have to make a cut. Or in other words: you can't expect every future addon or programm runing on your old gear.

 

Beside this: for my feeling 20 fps in a town is a very good rate and absolutly playable. So be happy!

 

My specs:

 

AMD Athlon 64 3700+ San Diego, @ 2.31Ghz with Hyper 48+ cooler, 36 degrees C at full load.

2 Gb DDR 400mhz

Asus A8

Radeon 9800XT with Zalman VF-700 Cu @ 12 Volt

 

 

Please tell me my specs are below average. Well, they aren't, not yet at least. And I'm getting quite p***ed off with all these new software titles coming out demanding more and more resources to do the same thing windown 98 could, just with some flash interface requiring you to have top-notch dual core systems. And take a look at VB suite 2003, and compare it to vb 6, yes, even the programming tools get inefficient. But then again, why bother if you can do the same thing in half the time with 4 times the needed resources? Right? :/

[ARM505]

It's more of an issue than just making the trees solid. The damage done to the chopper has to be correct - a helo doesn't just explode if one blade clips a tree, it can actually cut through smaller branches etc. And that's a real problem - thats quite a CPU load to implement that. Plus, there's the AI LOS issues. Currently, the AI sees right through trees. How would it be fair if we couldn't see them, yet they could see and target us? Obviously it wouldn't be, so quite complicated LOS calculations would have to be performed. And we already know what a load it is just to even draw the trees, let alone do all these other things....I don't see them changing the solidity of the trees just yet, unless there's some bright solutions to these kind of problems, that are feasible with current hardware. (Please can we not have another FSX 'This software is made for computers built three years from now!')

 

And I'm not even mentioning synchronising all of this in MP (it's been mentioned before).

[Haegar]

My specs:

Please tell me my specs are below average. Well, they aren't, not yet at least. And I'm getting quite p***ed off with all these new software titles coming out demanding more and more resources to do the same thing windown 98 could, just with some flash interface requiring you to have top-notch dual core systems. And take a look at VB suite 2003, and compare it to vb 6, yes, even the programming tools get inefficient. But then again, why bother if you can do the same thing in half the time with 4 times the needed resources? Right? :/

 

Right. In case of some programs.

But I see a significant progress in simulation. Think back to the "98" flightsims and compare them to the actual ones.

You can't have better FMs, physical correct bouncing bullets, aerodynamic computations for every single rotorblade, more and more detailed 3d-model graphics, real weather effects and and and - without more powerfull hardware. And thats what we are talking about - not VB and all this crap.

Nobody will force you to fly actual sims, you are free to use 98er progs on your actual (and for sure not outdated) gear - but is this what you realy want?

[Boneski]

Threads like this are great!

 

 

People want all this hardcore stuff added to the game to prevent them from flying through trees...

 

Wow... just a few years ago trees of Lock On's volume where not even present in any flight sim game.... now you have forest and heavy simulated wood areas that people want to be solid...

 

SO what is being asked is to have the trees, which have to number in the 100'000's to be tagged with destructive collision?

 

How would they do that? It would seem like a major wasted of CPU cycles to have to render all of the trees in the game as solid. Even if the player's own ship or AI is no where near them??

 

Sounds like too much work for something that the player can just avoid doing...i.e.. flying thru the trees... just pretend they are solid.

[Haegar]

We are not talking about a "simple" flightsim anymore - we are talking about an upcoming helicopter-simulation.

Tactics for an attack-helicopter are "slightly" different than for a fighterjet. Seen from a F16 trees are maybe "eyecandy", from an A10 only "obstacles", but for combat-helos they are important, because the pilots can hide behinde them, scan the area without been detected, the trees offer cover and so on...

See the point? Trees, forests are important for a good helicopter simulation. But if they are not solid a lot of realism would be lost, because there is no advantage without a price in real life - no tactical advantage without the danger to collide.

 

just a few years ago trees of Lock On's volume where not even present in any flight sim game.... now you have forest and heavy simulated wood areas that people want to be solid...

Wrong. Example: In 1998 Razorworks released "Enemy Engaged Apache versus Havoc" and there already where trees and forests which the player where able to use in a tactical manner.

[Witchking]

well....let us wait to see what ED has to say about this matter.

 

Hopefully they do the right thing. Becos its no fun if you can't use trees as cover and so on. Thats the basic concept and fun with a heli.

[504MrWolf]

if i remember the new tree textures are 512x512 (might have changed).

[D-Scythe]

The old ones were actually about 32*64. There might've been a few select ones at 64*128, but the vast majority were painfully low res.

 

I thought the new ones were still being worked on, but that may be just me.

[ZoomBoy27]

Another option is for groups or lines of trees to be turned into forest collision boxes. I think EECH did that.

[Haegar]

Yes, the forests where "blocks" with single trees around them. So you gut the "impression" of a forest.

For me it worked and I used it often to play "cat and mouse" with the enemy helos - that was real fun :)

[Groove]

As long as i can hide behind a ridge of trees and pop-up for an attack im fine with every solution. But the trees must be solid and the AI shouldnt be able to look aim through the trees. I think everyone agree with me that this is a vital part of a helicopter simulation.

[ALDEGA]

My specs:

 

AMD Athlon 64 3700+ San Diego, @ 2.31Ghz with Hyper 48+ cooler, 36 degrees C at full load.

2 Gb DDR 400mhz

Asus A8

Radeon 9800XT with Zalman VF-700 Cu @ 12 Volt

I'm sorry but this is not a high end system at all. The best part is probably the amount of RAM.

Your video card is pretty much ancient history (late 2003?) ;)

 

And take a look at VB suite 2003, and compare it to vb 6, yes, even the programming tools get inefficient. But then again, why bother if you can do the same thing in half the time with 4 times the needed resources? Right? :/

You have absolutely no idea what you are talking about.

[ALDEGA]

The old ones were actually about 32*64. There might've been a few select ones at 64*128, but the vast majority were painfully low res.

 

I thought the new ones were still being worked on, but that may be just me.

The thing is that there are a high number of trees, which means you have to take that low res and multiply by a few hundred, if not thousand. Not exactly friendly for the fill-rate. The resolution is only an issue when flying low, which is what we're ... probably ... going to be doing in LOBS.

[504bigtonka]

Quote:

Originally Posted by Force_Feedback

And take a look at VB suite 2003, and compare it to vb 6, yes, even the programming tools get inefficient. But then again, why bother if you can do the same thing in half the time with 4 times the needed resources? Right? :/

 

You have absolutely no idea what you are talking about.

 

-----------------------

 

hmmm.....

 

VB (cant say Ive used it thankfully ;) ) and graphical quality notwithstanding - Force_Feedback's comment holds true quite well...

 

Lets take a typical "Hello World" program, the simplest of all - typically a compiled executable was a few bytes in the late 80's - early 90's , by the mid 90's quite a few Kb (at least!) these days a few hundred Kb (if not a lot more depending on environment) - it doesnt do anything different than it did back then!! (and yes Im keeping this simple ;) )

 

Now thats a simple program - look at program bloat (in every aspect of programming)

 

FSX really comes to mind here - it is nicer than FS9 but _that much_ nicer for the resources needed?

 

Not arguing but in some scenarios Force Feedbacks statement is correct (and in many ways quite conservative....)

[D-Scythe]

The thing is that there are a high number of trees, which means you have to take that low res and multiply by a few hundred, if not thousand. Not exactly friendly for the fill-rate. The resolution is only an issue when flying low, which is what we're ... probably ... going to be doing in LOBS.

 

You ever hear of mipmapping/LODs? ;)

[ALDEGA]

You ever hear of mipmapping/LODs? ;)

Your mipmaps are going to be larger respectively, otherwise the change between the mipmaps could be too big (visually). ;)

 

Besides, you have to change the mipmaps of the trees, which afaik are big blocks of geometry, not invididual trees. This may cause some graphical oddities if the mipmap LOD distance isn't far enough.

[ALDEGA]

hmmm.....

Lets take a typical "Hello World" program, the simplest of all - typically a compiled executable was a few bytes in the late 80's - early 90's , by the mid 90's quite a few Kb (at least!) these days a few hundred Kb (if not a lot more depending on environment) - it doesnt do anything different than it did back then!! (and yes Im keeping this simple ;) )

Are you sure you're compiling the same, most basic, C++ source, with optimizations for footprint?

 

VB and similar languages are not made for runtime performance or small footprints. They're designed for rapid application development.

 

Besides, comparing VB6 to VB.NET is just completely wrong.

 

You might as well compare cars from the 80's to a cars from the 2000's.

"oh no, these cars keep getting more expensive, but they seem the same"

They're not exactly the same, not at all ;)

 

If you can't accept that you have to upgrade relatively quickly, when you want to play PC games at high settings, then you should consider switching to consoles.

[504bigtonka]

Are you sure you're compiling the same, most basic, C++ source, with optimizations for footprint?

 

VB and similar languages are not made for runtime performance or small footprints. They're designed for rapid application development.

 

Besides, comparing VB6 to VB.NET is just completely wrong.

 

You might as well compare cars from the 80's to a cars from the 2000's.

"oh no, these cars keep getting more expensive, but they seem the same"

They're not exactly the same, not at all ;)

 

If you can't accept that you have to upgrade relatively quickly, when you want to play PC games at high settings, then you should consider switching to consoles.

 

my thought were more based on the evolution from assembler, through ANSI C/pascal, through C++ with whatever magical toolkits/modules/API kits etc etc.... codewise very similar but resource requirements can be a world (or 5!) apart ;)

 

"VB and similar languages are not made for runtime performance or small footprints. They're designed for rapid application development." - that isnt necessarily a good thing IMHO ;)

 

The reality is yeah we need to upgrade year in and year out (and yes I do this - and no I dont want to play consoles :) ) In a perfect world though when referring we perhaps shouldnt need to (at least quite as often anyway!) ;)

 

for the code that is.... ;)

 

Of course graphics textures ARE big and we need the resources to be able to handle those - but thats a different aspect.

 

 

Oh and I prefer old cars BTW ;)

[D-Scythe]

Your mipmaps are going to be larger respectively, otherwise the change between the mipmaps could be too big (visually). ;)

 

Besides, you have to change the mipmaps of the trees, which afaik are big blocks of geometry, not invididual trees. This may cause some graphical oddities if the mipmap LOD distance isn't far enough.

 

Yes, but that wasn't the point I was trying to make. The point is that fill-rate is NOT gonna be hundreds to thousands of times heavier, as you have suggested (unless you're running on some super-high tree density setting, but then if you are then you're probably running with a pretty good GPU in the first place).

[S77th-ReOrdain]

Don't think there is a reference for trees in the Meinit.xml file (could be wrong). However, I tried making trees and forests collision capable once in the Lock On\Bazar\foresttable.sht and Lock On\Bazar\treestable.sht. by changing the collision reference from "false" to "true". I had no success. Lock On did not load and gave me an error instead. Please back up your files if you attempt to do this, or it may cause a headache. Incidently, if anyone does figure this out, please share.

[Nate--IRL--]

I seem to remember that the collision detection option for the trees (by text edit only) was taken out in version 1.02 or 1.01 can't remember which.

 

Nate

 

EDIT :- BTW it should be pointed out that the was absolutly NO performance penalty involved with the collision detection on, it was just that the AI (especialy helicopters) couldn't see them and frequently flew into them. = BOOM

[Witchking]

As long as i can hide behind a ridge of trees and pop-up for an attack im fine with every solution. But the trees must be solid and the AI shouldnt be able to look aim through the trees. I think everyone agree with me that this is a vital part of a helicopter simulation.

 

amen!

[ALDEGA]

my thought were more based on the evolution from assembler, through ANSI C/pascal, through C++ with whatever magical toolkits/modules/API kits etc etc.... codewise very similar but resource requirements can be a world (or 5!) apart ;)

 

"VB and similar languages are not made for runtime performance or small footprints. They're designed for rapid application development." - that isnt necessarily a good thing IMHO ;)

If every piece of software today had to be created (completely) using assembler code, then there would not be a LockOn today ;)

 

Developing in C++ is a lot faster than developing in assembler code. This is definitely a good thing IMHO ;)

 

Assembler code isn't even the lowest level, you know :D