feature freeze time

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

feature freeze time

Post by safemode »

It looks like we're ramping up development to a decent level and it's all relatively necessary stuff.

To keep things going in the same direction, i think we should all agree to an absolute feature freeze to the vegastrike source.

What that would mean is that _only_ bugfixes and documentation commits would be appropriate from now until release.

As far as bugfixes go, only those that are critical or minor ones that require non-invasive changes (nothing that would require rewriting whole sections of code).

Hopefully this shifts some activity towards furthering the goal of actually putting something out. Since i'm afraid the renewed activity may give rise to the urge to just continue to rewrite and fix large-scale things (that need to be fixed, not arguing that) and push back releasing yet again.

We'll have to put incremental release changes to after this release. In the meantime, One thing we might be able to do is freeze a python script that pulls the /data dir from sourceforge.net's mirrors and ship it with vegastrike's bins then if /data is not found (or an older version) we can have vegastrike execute this python bin and pull it's own data.

This would be something geared towards linux rather than windows. Linux distributions are not happy about shipping our huge amount of data that we require. Having the bins pull their own data files from sf.net means they can update their versions of vegastrike rapidly.

This would be an interim fix until we get incremental updates in place. The version check against the data dir and subsequent conditional call to the frozen python bin would be the last feature added to vegastrike if everyone agrees.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

I'll document the collision system, collection.cpp/.h, options (need to move more getVariable instances over to this too, but can wait until after release), probably vsfilesystem too.

I can also document the cmake system that we have locally and create a more user friendly howto on getting cmake working. Along with making the cmake output more verbose in explaining targets.


I'll try and document more than that, but that's what i definitely want to get done off the top of my head.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

I agree about a freeze. Just keep in mind there's changes in the pipeline in the techniques part of the code that
should definitely be in the release. I'm working on reorganizing shaders, and this is a prerequisite for Klauss
to finish organizing the default shader selection parts of the code. Once this is all done, vegafig will change,
with more comprehensive shader choices.
Besides bug-fixing, we should finish getting rid of warnings under cmake. If the whole idea of generating
interest by putting out a release, and getting new development help as a consequence, actually works, we
should at the very minimum have code that doesn't issue warnings. For the sake of respect, if nothing else.
(Not that that respect won't be challenged the moment they see public data members in classes; but you know
what they say about first impressions... No warnings is like putting a clean shirt on the code. Far from suit and
tie; but before putting on suit and tie it should get a deep bath, first, anyways.)
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

warnings generated by cmake are what i've been trying to squash with my recent commits (prior to refactoring).

Most of these are comparisons between signed and unsigned, in addition to assignments to unsigned by signed variables.

Also, comparison between unsigned and size_type

Also, not putting parenthesis around conditional assignments ... like for(;un = some->un_iter;++un) should be for(;(un = some->un_iter);++un)

Also, not having braces around if statements generates a warning in some situations regarding ambiguous else statements. I believe this is a warning regarding readability rather than the compiler possibly getting confused.

Some switch statements still dont have default cases.


Squashing those would be the majority of the remaining warnings.

Note: vegaserver builds 100% without warnings with -O0, now, -O2 is a different story as is -O3. I have not tackled those yet.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

safemode wrote:warnings generated by cmake are what i've been trying to squash with my recent commits (prior to refactoring).
But you're still working on them, right?
I just want to know because, if you're not, I'd be eager to tackle them.
Most of these are comparisons between signed and unsigned, in addition to assignments to unsigned by signed variables.

Also, comparison between unsigned and size_type
Yep.
Also, not putting parenthesis around conditional assignments ... like for(;un = some->un_iter;++un) should be for(;(un = some->un_iter);++un)
I think what it wants to see, rather, is,
for(;(un = some)->un_iter;++un)
EDIT:
Sorry, got confused; thought it was >= I was looking at. That's evil...
Also, not having braces around if statements generates a warning in some situations regarding ambiguous else statements. I believe this is a warning regarding readability rather than the compiler possibly getting confused.
Indeed, but readability matters. Uncrustify does have bugs; sometimes it removes braces that --according to the configuration settings-- it shouldn't.
Some switch statements still dont have default cases.
Many.
Note: vegaserver builds 100% without warnings with -O0, now, -O2 is a different story as is -O3. I have not tackled those yet.
-O3 makes vegaserver segfault. Which means there's some bad code in it; --pointer aliasing across function calls?
For server code, this is a BUG, because server code should be multi-threading and multi-processing and multi-everything-friendly
more than any other kind of code should be; so no aliasing should definitely be assumable.
But anyhow, for now I changed Makefile.am back to its original -O2 default, yesterday, or the day before.
Is there a way to limit optimization level for vegaserver?
What we need is separate optimization levels for vegastrike and everything else; I don't see why so many unrelated targets
should all be -O2, or else all be -O3. Things like mesher don't need ANY optimizations.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: feature freeze time

Post by Deus Siddis »

Is new content allowed to be added after a feature freeze?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

Certainly; as long as it doesn't depend on features being worked on that won't make it to the release, of course.
By the way, I've been thinking of tackling your asteroids; but have questions; I'll post to a thread in the art forum.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

chuck_starchaser wrote:
safemode wrote:warnings generated by cmake are what i've been trying to squash with my recent commits (prior to refactoring).
But you're still working on them, right?
I just want to know because, if you're not, I'd be eager to tackle them.
Yes, but i had to stop for the refactoring. Just way too much collision .... i had to go line by line through a diff and re-modify a commit i made to my branch but did not put it into trunk (forgot) prior to the reformat commits to trunk. I did not want to repeat that. So now that the mass code changes are done, i can get back to the warning hunting.
Also, not having braces around if statements generates a warning in some situations regarding ambiguous else statements. I believe this is a warning regarding readability rather than the compiler possibly getting confused.
Indeed, but readability matters. Uncrustify does have bugs; sometimes it removes braces that --according to the configuration settings-- it shouldn't.
indeed, so some warnings will exist no matter what. Different compilers will produce different warnings, we just need to focus on the ones that mean something.
Note: vegaserver builds 100% without warnings with -O0, now, -O2 is a different story as is -O3. I have not tackled those yet.
-O3 makes vegaserver segfault. Which means there's some bad code in it; --pointer aliasing across function calls?
For server code, this is a BUG, because server code should be multi-threading and multi-processing and multi-everything-friendly
more than any other kind of code should be; so no aliasing should definitely be assumable.
But anyhow, for now I changed Makefile.am back to its original -O2 default, yesterday, or the day before.
Is there a way to limit optimization level for vegaserver?
What we need is separate optimization levels for vegastrike and everything else; I don't see why so many unrelated targets
should all be -O2, or else all be -O3. Things like mesher don't need ANY optimizations.
-O3 does things that can break the language's spec. Just like things like -ffast-math breaks the language. Now, chances are we dont hit the corner cases that this is true for, and the code is indeed buggy, but -O2 is your last safe optimization level before you start doing things that can break perfectly good code that just happens to do things that can confuse compiler optimization. I would consider -O2 to be a target for warning-free building. -O3 functionality would be a bonus, but not a pre-requisite for release. Many _Many_ math intensive and complex projects will fail with -O3.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

True. And the fact is, the best way to optimize code for speed is to optimize 90% of it for size, and
only optimize the critical functions for speed, using pragmas; so this is all neither here nor there.
You get MUCH better performance that way than by optimizing everything for speed.
But I probably won't be doing performance analysis before release, so let's just -O2 it for now.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

when i last did performance profiling in vs... it's very confusing at first to find what is taking along time _per_ run vs what we spend most of our time in doing. For instance, we spend _a_lot_ of time traversing our unit list. But that's extremely fast, we just do it a shit ton of times. I dont think we have any real inefficient functions....this code-base is over a decade old, and much of the horribleness we see in the code is in direct relation to trying to make it faster.

The parts of code we do know that has a problem are graphics related and IO related. The first being things like viewing fullscreen textures ...more noticable on lower end (like my geforce 6600) cards. Ie, panning the view of a planet that takes a good portion of the screen grinds things down.

The second part is creating units. This operation blocks and everyone knows it. No need to profile that.

Those are our two big guys. Once we tackle those, it's nitty gritty time with everything.

Though, that kind of work can wait until after release. We just have to figure out what the new hardware requirements for VS are with all the new bells and whistles.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

If you're talking about target hardware in terms of graphics, svn up data, and have a look in techniques.
There's folders there for every hardware target, by pixel shader standards. Inside each folder there's
a README that lists the gpu brands and models for that target.

The shader selection drop box in vssetup will change accordingly. Choices of Shader Quality will read like,
  • ps4.1 (Nicest; for eg: GeForce 300, HD3000-4000)
  • ps4.0 (Nice; for eg: GeForce 8,9,200; HD2400-2900)
  • ps3.0 (Okay; for eg: GeForce 6,7; X1300-1950)
  • ps2.0b (Oldish; for e.g.: GeForce FX; X700-850)
  • ps2.0 (Old; for e.g.: GeForce 4; Radeon 9500-9800)
  • ps1.3/1.4 (Older, for e.g.: GeForce 4; Radeon 9000)
  • ps1.0-1.2 (Oldest, for e.g.: GeForce 3, Wildcat, Xabre)
  • NO shader (Ancient; e.g.: TNT)
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

chuck_starchaser wrote:If you're talking about target hardware in terms of graphics, svn up data, and have a look in techniques.
There's folders there for every hardware target, by pixel shader standards. Inside each folder there's
a README that lists the gpu brands and models for that target.

The shader selection drop box in vssetup will change accordingly. Choices of Shader Quality will read like,
  • ps4.1 (Nicest; for eg: GeForce 300, HD3000-4000)
  • ps4.0 (Nice; for eg: GeForce 8,9,200; HD2400-2900)
  • ps3.0 (Okay; for eg: GeForce 6,7; X1300-1950)
  • ps2.0b (Oldish; for e.g.: GeForce FX; X700-850)
  • ps2.0 (Old; for e.g.: GeForce 4; Radeon 9500-9800)
  • ps1.3/1.4 (Older, for e.g.: GeForce 4; Radeon 9000)
  • ps1.0-1.2 (Oldest, for e.g.: GeForce 3, Wildcat, Xabre)
  • NO shader (Ancient; e.g.: TNT)

Except i have a pci-x16 geforce 6600 that can't handle panning across a planet if i'm close enough that it takes up the screen more than 50% without dropping to well below 30fps. This is true of jump points and i'm pretty sure any large texture . With or without shaders. (in fact, i mentioned before that the game would drop me out of the shader i started out with and go shaderless because it detected framerate dropping to crap). You mentioned this isn't a shader issue, so depending on the shaders to determine what it can run on is not sufficient. while the shader may be suitable for hardware like a geforce3 or 4, the rest of the graphics in the game is likely not.

we need a baseline for no shaders as to the performance we can pull from the game on lower end hardware, then add shaders and go from there.

ideally, we would figure out the gpu memory load of an average system. This would give us a bounds on how much gpu memory is needed. Having less than this would result in massive memory thrashing that would bring even a fast enough gpu chipset to it's knees.

Then we need to figure out how fast the gpu has to be to handle things like close encounters with large meshes.

only after that would we consider what can handle each shader.

Putting the TNT up there as viable graphics hardware is either joking or you have some frankenstein system with crazy new hardware but chose to use a tnt video card for fun. VS loads up well over 256MB of textures when you start it. That wont include active memory needed for manipulating them as well as other operations. In addition to that, you have huge models and textures to deal with in addition to a lot of them.

We need to set up some standards for what we consider minimal performance,and recommended minimal performance before we attach hardware to options. Video card options are also likely to impose a non-gpu requirement ...things like loading more textures or non-gpu processing will alter how we describe what hardware fits what options.

I think eventually we're going to have to go towards an auto-detect mechanism for determining options. it's just gonna get too complicated for users. Like create a test mission that will auto-control the user's ship and mimic various load-inducing situations and repeat under various combinations of options, then pick the best performing one based on framerate drop percentages and a baseline min. ie, pick the highest options that produce the least amount of droppage below our minimum allowed. And if no option produces such a number, the game can report to the user that their hardware doesn't meet requirements ...but let them play at minimum options anyway. Test could be like a 3-5 minute test. Should be doable all in python too. since it's possible to change shaders on the fly i believe.
Ed Sweetman endorses this message.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: feature freeze time

Post by pheonixstorm »

Minimum, nothing slower than a P4 (slowest) and no video below a gefore 4.

*EDIT* If you look at some of the current class mmos you will see that you can still run them on a g5 (maybe a bit lower) with all the options turned way down or off and still get decent performance and video quality. The problem may be more of an issue with code quality over hardware capability.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

There's no need to raise the minimum for the gpu; we already have support for gpu's all the way down to TNT, and
there's no reason to remove such support. It looks like crap, but it plays.

What we could use is a vssetup setting for texture size reduction, for people with little video memory.
In fact, maybe we should have a drop box for amount of video memory, like we have for system memory.
If the user selects 128 megs, we know we need to strip off the top LOD's of textures.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

I dont think it's reasonable to let people think this game will play at a useable level on any videocard that has less than 512MB of memory circa the nvidia 7000 series gpu's. Sure it will run, but it's not going to be playable at all when you start dogfighting near a planet/base/jumppoint. just wont.

will some people overlook those hiccups, sure, but the object of a minimum is not to disallow people from using that hardware with the software, but to just give them a heads up that "yes, we dont care if your crap hardware doesn't work, we didn't intend it to."


And when comparing the game to other games, keep in mind, VS systems are _HUGE_. our textures are huge. our effects are much more accurate and better quality than many of these mmos. *caugh*startrek*caugh*. Regardless of the quality of our meshes and state of the game (not having any sort of plot and lack of video and animation and cartoon like characters etc)... Vegastrike is pretty far up there when it comes to graphics. I'd be willing to bet the only things that beat it have highly paid development teams that get to exploit hardware api's and their software only works on one (guess which) os.

That's not to say we can't improve the code, but dont underestimate how demanding the featureset is. This is no tuxracer :)
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

Well said. And it will keep getting up there.
In a few months we'll be at leading edge commercial game quality, I predict.
BTW, I have 320 megs of vid ram; and I got no problems.
Anyways, you already have code to strip textures' top lod's; I think it merits to think about
using it for all textures greater than 512, if video ram is less than 256 megs. Just an idea.
People with video in the chipset and low vid mem often suffer insufferably low framerates
(and even with good gpu's; --we had one such case recently at the pu forum).
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

stripping lod's is only part of the problem. we have to reduce the number of textures being loaded at any given time by controlling the number and variety of units. We ought to reduce the sizes of systems in addition to just the number of active ones. If we want to truly allow lower end hardware to participate.

Since we can't dynamically reduce the complexity of the meshes, we could at least lower the cpu load of the collider by creating a low end collision system. On lower end hardware, we could allow the use of a simplistic collider mesh, where we find a way to reduce the number of triangles to a minimum. Basically, disallow flying into bases / flight decks and create simple polygons to represent the ship. 8 faces is way less stressful on the cpu than thousands.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

safemode wrote:stripping lod's is only part of the problem. we have to reduce the number of textures being loaded at any given time by controlling the number and variety of units. We ought to reduce the sizes of systems in addition to just the number of active ones. If we want to truly allow lower end hardware to participate.

Since we can't dynamically reduce the complexity of the meshes,...
Freeze! I just got a crazy idea... For models without LOD's, we could have a cube somewhere that the engine uses as a default LOD. Would that help?
EDIT:
Maybe do a resizing of the cube in code to match the ship's width, height and length, if the data is available.
we could at least lower the cpu load of the collider by creating a low end collision system. On lower end hardware, we could allow the use of a simplistic collider mesh, where we find a way to reduce the number of triangles to a minimum. Basically, disallow flying into bases / flight decks and create simple polygons to represent the ship. 8 faces is way less stressful on the cpu than thousands.
If the model has LOD's, we could at least switch to a lower LOD for collision computations.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

chuck_starchaser wrote: Anyways, you already have code to strip textures' top lod's; I think it merits to think about
using it for all textures greater than 512, if video ram is less than 256 megs.
We also have to turn off linear/bilinear filtering when we do this, or force screen resolution down. I noticed more cpu usage (poorer framerate) when using only lower LOD's. Sure mem usage goes down a bit, but who cares if it is going to still bring the system to a crawl. Anti-aliasing type stuff really hurts when we try to use low quality settings.


People with video in the chipset and low vid mem often suffer insufferably low framerates
(and even with good gpu's; --we had one such case recently at the pu forum).
not the 950gma guy ...right? cuz that's not a good enough gpu for basically anything. When gpu speed is up to par, but performance still suffers,i tend to think it's the memory that's to blame. I can achieve very noticeable performance increases by overclocking my video card's memory ...almost none when overclocking the gpu itself. This tells me that my video card is fast enough, but it's ram is not, or it's insufficient in size and involved in serious thrashing, so the higher clock rate helps significantly. An integrated chipset uses system memory, and if system memory was fast enough, well.. i wouldn't have much of a change in performance by overclocking the video card's memory. Also, most integrated setups lock you down at 256MB system memory dedicated to graphics, and that's just not enough. Your video card may have just enough ...but i'm willing to bet it's just fast enough for you to not notice the thrashing going on, as little as it may be, the difference between 300+ mb on video memory and 256MB system memory is huge. No amount of settings may be capable of negating it without seriously altering the gameplay for these people vs people running at normal settings.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

chuck_starchaser wrote:
safemode wrote:stripping lod's is only part of the problem. we have to reduce the number of textures being loaded at any given time by controlling the number and variety of units. We ought to reduce the sizes of systems in addition to just the number of active ones. If we want to truly allow lower end hardware to participate.

Since we can't dynamically reduce the complexity of the meshes,...
Freeze! I just got a crazy idea... For models without LOD's, we could have a cube somewhere that the engine uses as a default LOD. Would that help?
EDIT:
Maybe do a resizing of the cube in code to match the ship's width, height and length, if the data is available.
we could at least lower the cpu load of the collider by creating a low end collision system. On lower end hardware, we could allow the use of a simplistic collider mesh, where we find a way to reduce the number of triangles to a minimum. Basically, disallow flying into bases / flight decks and create simple polygons to represent the ship. 8 faces is way less stressful on the cpu than thousands.
If the model has LOD's, we could at least switch to a lower LOD for collision computations.
I thought meshes were meshes were meshes. The only thing that changed with LOD was texture representation. Collider meshes are built off of the actual mesh, at loadtime, so i can control how it's built if i want. It's invisible so it wont visually matter to the player. The ship mesh is hard-coded. Changing it changes how the textures are applied to it, so i thought it was static, never changing.

I know collider meshes dont get regenerated in some LOD manner. They are static once created, and i'm pretty sure model meshes are too.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

ideally, the best way to reduce complexity of the collider without ruining the visual look of the models is to have modelers provide two meshes. One that gets used for display and such. The other would only be used by the collider. It can be a reduced texture to the level of like, <10% of the original vertexes. This would reduce any sort of runtime cpu load for auto-generating stuff, and still provide a somewhat decent collider experience for the player with minimal artifacts. It could even be done on a per-availability basis. So all the meshes wouldn't need to be updated at once. We would just call for the low res mesh if the vs config says to, and if it's there use it,otherwise use the regular one.


edit: an idea for the next release anyway :) All that's important for this release is that we document, and squish warnings down and finish the work that's already been started with the shaders.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

I'm of the exact opposite opinion; that's increasing the workload for artists for no reason.
Anyways, what I meant was this:
My understanding is that the engine supports having a collider mesh; but not all models have one.
When they don't, the collider uses the real mesh.
So, my suggestion was, better put:

Code: Select all

IF ship has no collider mesh 
  IF ship does have LOD's
    IF the cpu sucks
      instead of the top LOD, use the second LOD for collisions
    FI
  FI
FI
As for the collision mesh having no lod's, true; though that's a decision made in coming up with
the bfxm format; not a universal law; and a pretty weird decision at that. But even weirder is
the decision of having a collide mesh in the first place. I don't understand. If the purpose was
to simplify the mesh, why not just set it in stone that the collision mesh is the second LOD?
And I understand even less the motivation for having a shield mesh specification. The vertex
shader (or the cpu) could easily generate one on the fly by inflating the second LOD along the
normals as it loads the file.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

Every object you hit in the game is hitting a collider mesh. The collider keeps a copy of the mesh in memory because it's not read-only in it's operations. And it has to be _fast_ so it doesn't store things in a format that is readable as a mesh for things like the graphics subsystem. Opcode supports sharing vertex memory, but we dont store our vertexes in a compatible format. I convert it on the fly when we load meshes.


A shield mesh is needed because the shields are round, not replicas of the ship's body. We have to bounce off the shield in cases where the shields are active. We could take away that feature and have shields only interact with energy weapons but then what about projectiles, we dont handle energy vs projectile weapons differently right now.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

Maybe then we should use the shield mesh for collisions.
Not sure.
I'm just trying to simplify a bit.
So, you're saying that there's no special collision mesh; that you convert it from the model's mesh on the fly.
So, how about converting the second LOD of the model (if available) into a collision mesh, instead of the
top LOD?

IOW, use this:

Image

instead of this:

Image
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

that's what i was suggesting, if there is a second mesh that the unit has, less detailed, i could use that to generate my collider mesh. But as far as i know, we only use one mesh per model and we dont do any sort of modification to this mesh once it's loaded...meaning we dont swap between different mesh LOD's. The only sort of LOD stuff we do as far as i know is texture related and is handled by GL transparently once we give it the mipmaps.

the special collider mesh is contained within opcode, it's not accessible or useable to anything outside of it. I read in the vertexes from the mesh we're using in-game and feed it to opcode in a format it understands.
Ed Sweetman endorses this message.
Post Reply