Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ogt_vox: ogt_assert in nTRN chunk for voxedit.io models #52

Open
mgerhardy opened this issue Jun 16, 2023 · 5 comments
Open

ogt_vox: ogt_assert in nTRN chunk for voxedit.io models #52

mgerhardy opened this issue Jun 16, 2023 · 5 comments

Comments

@mgerhardy
Copy link
Collaborator

There is an external editor available that is creating invalid nTRN chunks where the reserved id is not UINT32_MAX. It would be nice to still be able to load the model files that were exported by this software.

vengi-voxel/vengi@993b9bb

@jpaver
Copy link
Owner

jpaver commented Jul 22, 2023

Hey @mgerhardy, thanks for the report. Not sure if this reserved field will be used in the future, so having the assert is useful to alert us when a new feature supported by MV is possibly being used within a given .vox file.

That being said, not sure it will be used -- MV development appears to have slowed down a lot so perhaps it's fine.

Can you confirm that the voxedit.io model is loadable by MV?

@mgerhardy
Copy link
Collaborator Author

Yes. Sorry for not mentioning it. The model loads fine in magicavoxel

@mgerhardy
Copy link
Collaborator Author

maybe another thing for the context object - hand in a warn or error function to log these things. But asserting would prevent loading these models - even if everything else would be fine.

@jpaver
Copy link
Owner

jpaver commented Jul 27, 2023

But asserting would prevent loading these models - even if everything else would be fine

It is possible for clients of the library to skip specific asserts if they need to by checking the message passed to the assert:.

void _vox_assert_msg(bool condition, const char * msg_str) {
  // condition wasn't violated? exit
  if (condition)
    return;
  // ignore specific asserts.
  if (strcmp(msg_str, "unexpected value for reserved_id in LAYR chunk") == 0)
    return;
  fprintf(stderr, "%s", msg_str);
  raise(SIGTRAP);
}

#define ogt_assert(cond, msg_str)    do { _vox_assert_msg(cond, msg_str); } while(0)
#include "ogt_vox.h"

...but I do sympathize. This sort of assert is really a warning of potential forward compatibility issues. I wonder if we should add an ogt_assert_warn so the library client can distinguish between fatal asserts and warning asserts, and then independently override them. eg

// implement a fatal assert
#define ogt_assert(cond, msg)   do {               \
     if ( !cond ) {                                \
       fprintf( stderr, "%s", msg_str )            \
       raise(SIGTRAP);                             \
  } while( 0 ) 

// implement a warning assert
#define ogt_assert_warn(cond, msg)  do {           \
      if ( !cond )                                 \
        fprintf( stderr, "WARNING: %s", msg_str ); \
  } while( 0 )
#include "ogt_vox.h"

...of course, we'd just turn these reserved_id asserts into ogt_assert_warn, and if ogt_assert_warn wasn't overridden by the client, ogt_vox would define it itself. eg.

// user didn't override warning assert? just map it to ogt_assert
#ifndef ogt_assert_warn
   #define ogt_assert_warn         ogt_assert
#endif

@mgerhardy if you think this is a good direction, feel free to put together a PR - otherwise, it may take me a while to get to it.

@mgerhardy
Copy link
Collaborator Author

@jpaver there we go - a PR is made. But the locations of the ogt_warn usage are still open for discussion I think. I'm not sure if I hit all locations or maybe even hit too many. Feedback welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

2 participants