View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006338 | Spring engine | General | public | 2019-11-13 04:00 | 2019-11-18 19:42 |
| Reporter | aeonios | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 104.0 +git | ||||
| Summary | 0006338: s3o features violate FeatureDrawDistance and FeatureFadeDistance | ||||
| Description | I'm only inferring that this is the case because I saw some trees that persistently faded out even when FeatureFadeDistance and FeatureDrawDistance were both set to 99999. I could find no significant difference (or any effect in changing the lua featuredef settings) between features which faded incorrectly and those that didn't except that the ones that faded were using the s3o model format. Not all s3o models have this issue either, but I suspect that not all s3o models have fade distance specified. | ||||
| Steps To Reproduce | art's oak trees demonstrate this issue (especially the smaller ones), while the ported palm trees from 0ad do not. | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | Irrelevant | ||||
|
|
"fade distance" is not a property of any Spring model format, and if you saw any fading it is impossible that both FeatureFadeDistance and FeatureDrawDistance were actually set to 99999. you can repeat whatever test you did with build 1444-gf0056cc (making sure to first type /featuredrawdist 99999 then /featurefadedist 99999 into the console) to verify there is no issue here. |
|
|
Look, if you want to see this happen it's demonstrated on Temple Redux. I set BOTH of those settings in springsettings.cfg on springboard, and I know springboard doesn't just overwrite your settings like some other games do. Here it is direct copy and paste: FeatureDrawDistance = 99999 FeatureFadeDistance = 99999 Also those UI commands don't exist, it can only be set from springsettings.cfg Also I can't get that engine version, but the engine used in zk (104.0.1-1435-g79d77ca) shows the same issues. Here are the same lines from zk's springsettings.cfg (with the "rock and wreck fade" setting set to off): FeatureDrawDistance = 600000 FeatureFadeDistance = 600000 And I still see features fade out and disappear. If there's no setting in s3o models that should cause this, then something is truly broken and I have no idea why it's doing this. |
|
|
"Also those UI commands don't exist" I quite clearly told you to test 1444-gf0056cc, *not* 1435-g79d77ca. Forget about springboard / springsettings.cfg and just do this: 1) download build 1444 from https://springrts.com/dl/buildbot/default/maintenance/104.0.1-1444-gf0056cc/win32/ 2) install 1444 and load up your map of choice with it 3) when ingame type /featuredrawdist 99999 and /featurefadedist 99999 to override whatever config values happen to be active 4) observe no feature fading whatsoever Since you are going to come to the same conclusion very soon, your real issue here will be the engine not loading the settings file you think it is. You can find out which config is actually being used by checking the first few lines of your infolog.txt, and if you set any non-default values for either FeatureDrawDistance or FeatureFadeDistance (such as 99999) in the *correct* springsettings.cfg then the "<User Config>" section further down infolog will list them for extra verification. Nothing about the fading logic itself is broken, so NCR once again. |
|
|
I know for a fact that that isn't the reason why this is happening, because in the springboard springsettings.cfg I also edited ground detail and scroll wheel speed settings. The ground detail was pretty obvious but the scroll wheel speed went from being positive to negative and the completely reversed direction is unmistakable. So I know that it was correctly reading the file that I edited. Again, NOT ALL FEATURES are doing this. The ferns on the same map do not fade out. If it was simply not seeing the settings at all then all the features would be fading out evenly, but they're not. I figured that maybe the oak trees were using DDS without providing mipmaps and that maybe trilinear filtering was causing them to disappear, but neither the oak trees nor the ferns are even using DDS textures. Both are tga and both use s3o model format. |
|
|
"So I know that it was correctly reading the file that I edited." Then you will certainly also be able to attach an infolog that actually shows the modified Feature* settings read by the engine, because (as I said before) the lines below "============ <User Config> ============" are a dump of every *non-default* config value in use. If your next reply does not contain a 1444 infolog proving you followed the steps given above and at least one screenshot, I'll nuke this report permanently. |
|
|
Addendum: I can spot exactly *ONE* type of feature (artoakgrandlo) disappearing (not "fading") on Temple Redux with Feature*Distance set to 100000. This feature has a predefined model radius of just 10 elmos, which results in the engine thinking it should become a fartex under the default UnitLodDist value of 1000 when its squared camera distance exceeds 10*10 * 1000*1000 elmos. Imposter objects are however not drawn if a feature has the (true by default) "should alpha-fade" flag, so all artoakgrandlo models end up being culled instead. Solution: either increase the radius or mess with UnitLodDist, this is not a bug regardless. |
|
|
wherever it's defined it isn't in lua. If that's the s3o then we're talking about an incredibly opaque NIH object type stored in binary format, doing something that should have been removed a decade ago. |
|
|
This can be closed. |
|
|
1) this is a case of a modeller *not* doing something (setting the radius metadata property to a sane value) rather than a model format "doing something" 2) how about I just hardcode a list of your maps and make the engine refuse to load .s3o models on any of them until you switch to .dae instead? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-11-13 04:01 | aeonios | New Issue | |
| 2019-11-16 01:20 | Kloot | Status | new => closed |
| 2019-11-16 01:20 | Kloot | Resolution | open => no change required |
| 2019-11-16 01:20 | Kloot | Note Added: 0020228 | |
| 2019-11-16 02:28 | aeonios | Status | closed => feedback |
| 2019-11-16 02:28 | aeonios | Resolution | no change required => reopened |
| 2019-11-16 02:28 | aeonios | Note Added: 0020229 | |
| 2019-11-16 11:42 | Kloot | Status | feedback => closed |
| 2019-11-16 11:42 | Kloot | Note Added: 0020231 | |
| 2019-11-16 11:45 | Kloot | Note Edited: 0020231 | |
| 2019-11-16 19:15 | aeonios | Status | closed => feedback |
| 2019-11-16 19:16 | aeonios | Note Added: 0020232 | |
| 2019-11-16 22:46 | Kloot | Note Added: 0020233 | |
| 2019-11-16 22:54 | Kloot | Note Edited: 0020233 | |
| 2019-11-16 23:42 | Kloot | Note Added: 0020234 | |
| 2019-11-16 23:45 | Kloot | Note Edited: 0020234 | |
| 2019-11-17 00:57 | aeonios | Note Added: 0020235 | |
| 2019-11-17 00:57 | aeonios | Status | feedback => new |
| 2019-11-17 23:20 | aeonios | Note Added: 0020237 | |
| 2019-11-18 19:42 | Kloot | Status | new => closed |
| 2019-11-18 19:42 | Kloot | Note Added: 0020244 |
