2024-03-29 11:17 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005829Spring engineGeneralpublic2017-11-09 16:58
ReporterAnarchid 
Assigned ToKloot 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version104.0 +git 
Target VersionFixed in Version104.0 +git 
Summary0005829: Collada model extents calculated erroneously for Z-up models, breaking nanoframes
DescriptionSpring's nanoframe renderer works by detecting model extents and progressing from bottom to top as the unit is completed. Possibly s3o can override this with height, but at least for Assimp models, the min extent is also used, and changing height helps little if the minimum is below zero on the height axis.

Spring's Assimp importer converts Collada models that have the up axis mapped to Z by rotating them so that they face Y-up. However, extent calculation *seems* to be done *before* this step. Since Z-up models will almost necessarily have geometry in negative half of the Y axis, this causes the Y-minimum to be below zero.

This effectively cause nanoframe build progress to start "below ground", and then to rapidly catch up - however, the nanoframe is completely not rendered until the progress reaches sufficiently high.

It is possible to workaround this issue for such models using the (otherwise undocumented) mins and maxs parameters in the metafile, consistent with the guess that it's extents calculation which is at fault.
Steps To ReproduceAttempt to build a Starlight or Gauss in ZK stable. Observe how the first lines on the ground appear only somewhere above 10%.

This is somewhat close to one sixth of total build progress, which is where we would expect first drawing to appear for one half of the first phase of build progress (which reaches 0% - 33%). It's not precisely there, and different between models, because of their height/width ratios.

Additional InformationTo confirm that extents workaround the issue: clone ZK's `factoryveh-remodel` branch (https://github.com/ZeroK-RTS/Zero-K/pull/2590), with special attention to commit https://github.com/ZeroK-RTS/Zero-K/pull/2590/commits/d6434b510a09737771f78b57cb3c8904a681d4bf

Maybe note that these metafile extent overrides work in Spring space, not in Assimp space. This is probably not relevant though.
Tags.dae, assimp, graphics
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0018617

Anarchid (reporter)

I've ruined the test case by applying the extents workaround to Starlight and Gauss. You can now replicate by cloning ZK and erasing `mins` and `maxs` from the corresponding metafiles in Objects3d/starlight.dae.lua and Objects3d/gauss.dae.lua.

~0018632

Kloot (developer)

this is fixed in develop, although I encountered some bogosity with ZK's energysolar (armsolar.s3o) which apparently has at least one vertex at y = 90042.164062.

sane models (including Z-up Collada files) should not ever need extent overrides.
+Notes

-Issue History
Date Modified Username Field Change
2017-11-06 19:28 Anarchid New Issue
2017-11-06 19:28 Anarchid Tag Attached: .dae
2017-11-06 19:28 Anarchid Tag Attached: assimp
2017-11-06 19:28 Anarchid Tag Attached: graphics
2017-11-06 21:37 Anarchid Note Added: 0018617
2017-11-08 15:19 hokomoko Changeset attached => spring develop 6a2b47f0
2017-11-09 16:58 Kloot Assigned To => Kloot
2017-11-09 16:58 Kloot Status new => resolved
2017-11-09 16:58 Kloot Resolution open => fixed
2017-11-09 16:58 Kloot Fixed in Version => 104.0 +git
2017-11-09 16:58 Kloot Note Added: 0018632
+Issue History