[blackhole]

Perhaps scripting should be enabled for things like cutscenes?

[ARSPR]

Well i've been searching through the collision detection code but have been unsuccessful in my attempts to understand it. I assume that somewhere in that mess its iterating through the vertices located on a ship? This is what would start hitting preformance with big models. In this case there are most likely optimizations that could be made to help out, but the main problem is that no physics engine can handle large amounts of polys, its limited by computer power. What lots of engines do is create a second model for collision detection, similar to Freelancer's infamous SUR files. I think that a HUGE preformance gain could be made by simply passing a different model to the collision detection routines. It could be an untextured POV file, or whatever you want, just make sure its not rendered. Then, take the loaded model file (which would basically be a lower-poly version of the high poly models, using one of the high poly model's LODs would be an excellent idea) and pass that to the collision detection routine or otherwise force it to use that model instead of the high poly one. You'll get less accurate collisions, but its doubtful that they will be noticed, espiecally if the collision model is properly done.

Thats my take on it. I'm going to look for something else to work on... *goes bughunting*

I'm no coder at all but thinking about the game logic I reached the same conclusion. But:

• I wouldn't use any low res LOD from the actual model because retail models, (or in fact any model till nowadays), haven't been built with this factor in mind so maybe you can get weird effects. (You'd need good updated models where there were a good match between LOD0 and the rest, so in other words you are breaking backwards compatibility).
• I'd use an auxiliary xxx-collision.pof model in a similar way as we have -shine or -glow auxiliary maps. If the xxx-collision.pof exists, this model will be used instead of normal one. If it doesn't, you just maintain actual behaviour. In this way each modder would have to build an adequate auxiliary model to improve the performance of the collision detection of every added or modified ship. (And our mighty DaBrain would have to update mediavps with a fully new set of auxiliary collision models).
• Of course, if you can optimize the existing routines to make them faster, that would be extra points.

(Just an idea, don't blame me too much if it is nonsense  )

[blackhole]

I think the other coders should look into that...

[Bob-san]

You'll need to be more specific on 6 and 22, but I think all of them are possible except for 18 and 19. While they could be coded, it'd be a mess and extremely prone to failure.

6) What I mean is follow a more-smooth flightplan (like you set the waypoints but the ship doesn't make a violent turn toward it, rather it slowly adapts by a more-smooth turn)
22) Using fake countermeasures and making sure that they always destroy the missile in pursuit... so that in a cutscene a countermeasure that should destroy the missile fails to go off (like they sometimes do) and ends up hitting the ship

On 18 and 19, those would both be enormously helpful to creating missions. If you could specify a sub-mod-pack, allowing you to get around some barriers like the ships.tbl limits or separate incompatibles mods without relaunching the game.

[Flaser]

Well i've been searching through the collision detection code but have been unsuccessful in my attempts to understand it. I assume that somewhere in that mess its iterating through the vertices located on a ship? This is what would start hitting preformance with big models. In this case there are most likely optimizations that could be made to help out, but the main problem is that no physics engine can handle large amounts of polys, its limited by computer power. What lots of engines do is create a second model for collision detection, similar to Freelancer's infamous SUR files. I think that a HUGE preformance gain could be made by simply passing a different model to the collision detection routines. It could be an untextured POV file, or whatever you want, just make sure its not rendered. Then, take the loaded model file (which would basically be a lower-poly version of the high poly models, using one of the high poly model's LODs would be an excellent idea) and pass that to the collision detection routine or otherwise force it to use that model instead of the high poly one. You'll get less accurate collisions, but its doubtful that they will be noticed, espiecally if the collision model is properly done.

Thats my take on it. I'm going to look for something else to work on... *goes bughunting*

AFAIK the engine already uses simplified models for collision detection, called bounding boxes.

One of the reasons why it's hard to convert high poly models to pof - or why such models have problems - is that either the BBox generation routines in pof constructor tools or the BBox code itself wasn't built with such high poly models in mind.

The second problem is that it checks for actual model intersection each and every frame, so things moving really fast tend to slip through. It is also limited in the number of intersections it can track, after a while shots start to ghost through models.

(Beams - hitscan weapons - are handled differently).

[blackhole]

Right - well i'm not even going to attempt to try anything like that. However, provided i can get the code to compile, i'm going to go ahead and try to replace all the directX 8 rendering code with directX 9.0c updated code using the most recent April 2007 SDK. I'm familiar with DirectX's API so this will be a good way for me to get to grips with the SCP code. If i actually succeed, then well, woohoo, we'll have DX9 stuff. Either way i'll use this to get myself ready for actual assistance for the team

[vamitul]

well.. before you start working on DX code.. maybe you should talk to taylor.. and read this: http://www.hard-light.net/forums/index.php/topic,47520.msg967131.html#msg967131

[blackhole]

Bleh, i don't really care. I'm just doing this for the heck of it. Its not like i'd commit the code or anything.

[karajorma]

I seem to remember that DX9 was a problem in that people running Win2K couldn't get the SDK to work (or was it Win98).

If you can fix DX that would be very useful though.

[blackhole]

People shouldn't need the SDK. All they need is that d3dx9_33.dll is either in their system32 folder or in the same folder as the FS2 executable. It shouldn't require the installation of anything.

I almost have the code compiling properly so at that point i should be able to make an assessment of it. DX8 API is very similar to DX9, so it should be easy.

[WMCoolmon]

You need the DX9 SDK to compile DX9. There's a version that works on Windows 2000 - I linked to it ages ago - but none of the recent versions do.

[WMCoolmon]

Oh, and Bob-san, I think you have a lot of great ideas for cutscenes, but your approach sucks. I really doubt that you "need" your requests filled any more than any other campaign out there. And we have no obligation whatsoever to you to fulfill those requests.

If you were to phrase your request more as a request and less as a "Give them to me or else", you might actually appear cooperative and some of the other campaigns that are working on cutscenes would dip in and add their support. As it is you didn't even bother to explain what you plan to use them for, so we have no guarantee that whatever time the SCP spends won't be used for your personal amusement and nothing else.

And finally, what you're asking for aren't just flags. All of them require interaction, possibly very complex interaction, with other parts of the code. 18 and 19 are basically impossible without tearing up the lowlevel filesystem, and the rest are just begging for conflicts with the AI code.

[blackhole]

To compile DX9 you simply need the lib files and include files - they are included in the SDK but you shouldn't have to install the SDK to compile it if you have the include and lib files stored in the FS2 project CVS itself. Course, that might be a pain to people downloading CVS. But windows 2000 was never really designed for DX9... Might it be possible to have a compiler option to simply exclude DX9? Or does DX9 *have* to replace the DX8 driver?

Thats considering that i can ever get this stupid thing to compile. I really think the 2005 project files are either horribly outdated, horribly made, or both. They don't use relative paths and i've encountered no less than 14 items that don't exist anymore, plus i had to totally redo all the reference paths. I just found out that the 2005 version doesn't even have 3 rather crucial projects, and when i tried compiling them with the converted 2003 project and putting them in i just get 320 "unresolved external symbol" errors.

Come on, why are many of those paths using 'C:\'?! the folder is in the CVS!

[taylor]

Or does DX9 *have* to replace the DX8 driver?

The current D3D code is dead, so adding DX9 will replace the DX8 code.  It's not optional at this point, unless you intend to also fix the horribly broken DX8 code.

There is a compiler option to exclude D3D, but that will have to include both DX8 and/or DX9, we aren't adding a new option just for DX9.  That would be nothing but a pain in the ass.

[blackhole]

Ah, well, if the DX8 code is already broken, i'll just replace it with DX9 code. Nice, working, good looking nextgen DX9 code... mmmmmmmm..............

Although i wouldn't call it broken because DX works better for me then openGL.

[taylor]

Although i wouldn't call it broken because DX works better for me then openGL.

The rendering issues that you listed are strictly data related.  The only reason that the D3D code doesn't show the same problem is because it doesn't support any of those features.  It's so out of date, messy, unoptimized, and feature deficient that it isn't even funny.  The only working graphics API that we have is OpenGL, period.

[Unknown Target]

If someone would fix the collision detection so as to make conversion easier, they would be my god.

Good luck blackhole

[blackhole]

I tried that, unknowntarget, but failed I'm hoping i'll hav emore success with this.  I think i will, considering i only got 150 errors after changing all the d3dx8.h references to d3dx9.h and changing all the objects from 8 to 9. Thats a relatively small number considering i just switched APIs

EDIT: MAke that 107 errors

EDIT2: Make that 32 errors. This is easier then trying to actually compile the source.

[Bob-san]

Oh, and Bob-san, I think you have a lot of great ideas for cutscenes, but your approach sucks. I really doubt that you "need" your requests filled any more than any other campaign out there. And we have no obligation whatsoever to you to fulfill those requests.

If you were to phrase your request more as a request and less as a "Give them to me or else", you might actually appear cooperative and some of the other campaigns that are working on cutscenes would dip in and add their support. As it is you didn't even bother to explain what you plan to use them for, so we have no guarantee that whatever time the SCP spends won't be used for your personal amusement and nothing else.

And finally, what you're asking for aren't just flags. All of them require interaction, possibly very complex interaction, with other parts of the code. 18 and 19 are basically impossible without tearing up the lowlevel filesystem, and the rest are just begging for conflicts with the AI code.

I'm not a programmer so I don't know how this all would go into the code. I don't know if it is an actual "need", but it would definitely be beneficial to some in-mission cut scenes that just don't work properly (some problems with it). I know you are not required to put in any of the requests, but they're just that--requests. If they are put in there, great! If not, well, people who want cut scenes for TSP will be downloading a lot of videos. I don't know exactly how to make my requests "friendly". That's a list of stuff that would definitely make my ideas work a lot better.

As of right now, at the end of a mission of TSP, we have plans for a pretty-complex in-mission cut scene. Cinematic sort of fight, a bit of a tribute to the FS2 Intro movie. That's stuff I'm not sure my system can run as a prerender and store all the uncompressed video. Yes, I know that they all require interaction--possibly very complex interaction. Now, I know 18 and 19 would be so hard to put into place, though they would make many campaigns much easier to get around limits (namely, by allowing you to have everything defined by-mission if necessary).

Now, most of that stuff is stuff that would make a lot of in-game cut scenes easier. Firing for a set number of times, fully-controlled movement without having to plot hundreds of way-points, the ability to change the shields (I'm not sure if this is available, though I think it might be), and have more control over how ships fight. The hard parts are finding what will work and what won't. I don't think that the game will accept rendering instructions without completely massacring this thing we call "compatibility". A render in DX or OGL would be great, but the movie scenes that come from it would be gigantic for a 2-minute battle. Also, sorting and exporting everything from the game would take forever, and importing all necessary stuff to a pre-renderer would be hard.

So, I hope we can get at least some of these implemented--it would definitely make TSP easier to do.

[Bobboau]

ok, nobody explained how collision detection works in FSO, so I should probly do that.

FS uses a BSP/octree, what is has is a tree and every node has a sortnorm, which divides the model in two, and a bouding box. colision detection only uses the bounding box portion of the tree. how it works is simple, if your test point is in a node's bounding box, then test all the children of that node, (and if a node is a polygon test it). so it should have about log2 complexity for finding a colision, the basic idea is prety good, but the implementation is hard to follow, I remember I did a rather huge revamp of the BSP system when I was working on the materials system, but that was a long time ago.. let me see if I can find that copy...

here we go

take a look at graphics/materials for what that whole thing was about
and model/bsp.cpp for why it's relivent here (note; I was effectively trying to make my own virtual function system for the bsp nodes), graphics/vertex buffers.h/cpp is still probably usefull to the project today, implementing it in a way similar to how I had in that code base would be a big step in the right direction, those were objects that I had origonaly designed for a totaly new game engine, and they are object oriented.