CommonMCOBJ Feedback

[StandingPadAnimations]

Hey there, StandingPad from the MCprep team here. I want to propose and discuss a draft specification that we at the MCprep team have been working on for the past week or so: CommonMCOBJ

CommonMCOBJ aims to establish a common standard for extra metadata in OBJ exports, such as texture export information, information about the selection that the OBJ is derived from, etc. In addition, it also aims to create standard ways to export world information (such as biomes) to allow for better animator workflows in 3D software.

We're in the process of gathering feedback from exporter developers to make adoption easier for exporter developers to adopt when we finalize version 1 of the spec.

Hope to hear back!

[TheDuckCow]

Hey Eric, as you consider this, it's probably also to have in mind the parallel conversation we're having with in the jmc2obj repo over here: jmc2obj/j-mc-2-obj#243

Keen to hear your thoughts! Kudos to StandingPad for spearheading this initiative.

[erich666]

I'm happy to add whatever tags get settled on, as needed.

FWIW, I currently do add a piece of metadata to OBJ exports. Right now only G3D recognizes it. It's to flag that textures should be treated as blocky (Minecraft style). The tag is like this, in the .MTL file:

newmtl grass_block_top
Ns 0
Ka 0.2 0.2 0.2
Kd 1 1 1
Ks 0 0 0
map_Ka tex/grass_block_top_y.png
# for G3D, to make textures look blocky:
interpolateMode NEAREST_MAGNIFICATION_TRILINEAR_MIPMAP_MINIFICATION
map_Kd tex/grass_block_top_y.png
illum 2

[erich666]

I should also mention that the header of Mineways OBJs all have the following type of data:

# Wavefront OBJ file made by Mineways version 11.06, http://mineways.com
# World: 1_19 Mangrove Swamp
# Terrain file name: C:\Users\ehaines\Downloads\mineways11.06\mineways\terrainExt.png
# Color scheme: Standard
# Thu Mar 21 09:14:37 2024

# Selection location min to max: -30, 64, -66 to -24, 319, -53
#   Non-empty selection location min to max: -30, 64, -66 to -24, 66, -53

# Set render type: Wavefront OBJ absolute indices
# Units for the model vertex data itself: meters

# 430 vertices, 302 faces (604 triangles), 110 blocks, 21 billboards/bits
# block dimensions: X=8 by Y=4 (height) by Z=15 blocks
# Elevation shading: no
# Lighting: no
# Transparent water: no
# Map grid: no
# File type: Export individual textures to directory tex
# Texture output RGB: YES
# Texture output A: YES
# Texture output RGBA: YES
# Export separate types: YES
# Export individual blocks: no
#   Material per family: YES
#   Split by block type: YES
# Make groups objects: no
# Custom material: YES
# Export lesser blocks: YES
# Fatten lesser blocks: no
# Simplify mesh: no
# Double all billboard faces: no
# Create composite overlay faces: no
# Center model: YES
# Use biomes: no
# Create block faces at the borders: YES
# Tree leaves solid: no
# Rotate model 0.000000 degrees
# Make Z the up direction instead of Y: no
# Scale model by making each block 1000 mm high
# Data operation options:
#   Fill air bubbles: no; Seal off entrances: no; Fill in isolated tunnels in base of model: no
#   Connect parts sharing an edge: no; Connect corner tips: no; Weld all shared edges: no
#   Delete floating objects: trees and parts smaller than 16 blocks: no
#   Hollow out bottom of model, making the walls 1000 mm thick: no; Superhollow: no
# Melt snow blocks: no
#   Debug: show separate parts as colors: no
#   Debug: show weld blocks in bright colors: no

# Full world path: C:\Users\ehaines\AppData\Roaming\.minecraft\saves\1_19 Mangrove Swamp
# Full terrainExt.png path: C:\Users\ehaines\Downloads\mineways11.06\mineways\terrainExt.png
# Full current path: C:\Users\ehaines\Downloads\mineways11.06\mineways

[StandingPadAnimations]

Thanks for responding!

The Mineways header was a source of inspiration when creating CommonMCOBJ, so for the most part the same values can be used (albeit with some different names and values); we use what OBJ exporters have already been providing as a reference to help with adoption. The only thing that might be a bit of a challenge is exported_bounds_min and exported_bounds_max, which defines a bounding box based on the in-game coordinates that make up the selection (as well as the max depth/height in export settings). I'm not sure how Mineways handles selections, but we do have a section on interpreting selections from in-game coordinates (though I will admit, it's not the best documentation, which we hope to tackle before finalizing version 1 of the spec).

As an aside, I think it might also make sense to put the CommonMCOBJ header under the Mineways header, just to avoid breaking scripts that use the Mineways header. CommonMCOBJ was designed to be placed anywhere in the OBJ for backwards compatibility reasons, just as long as it has the correct start and end markers.

[mmdanggg2]

At a glance it looks to me like this line in the existing header is already exactly what the exported_bounds would be

# Selection location min to max: -30, 64, -66 to -24, 319, -53

[erich666]

Separate header is fine if need be, just one more (small) thing to output from Mineways. Though, like you say, a lot's similar, so maybe there's a way for me to avoid duplication. Let me know when things are settled and I'll add the code to Mineways. I suspect all I need to do is add COMMON_MC_OBJ_START and END lines in the right places and move stuff that the spec doesn't understand to lines after END. Thanks for making it easy!

I've submitted a PR of little fixes to the README (my tricks: paste the text into MS Word to turn up bugs, and also run my chex_latex tool over it, just to see).

[StandingPadAnimations]

Sounds like a good plan 👍

[StandingPadAnimations]

CommonMCOBJ V1 has been finalized now 🎉

We've created a reference implementation of CommonMCOBJ called cmc2OBJ, which should help in comparing output. If you're curious, here's the section that outputs the header (note that it's written in Kotlin)

[erich666]

I've got CommonMCOBJ running on my machine. How do I test the header output? Does this program read in an exported OBJ? Or is the header just meant for downstream users?

Also, I did what I thought was a simple export: select a region by left-mouse-button drag and then hit the export button:

But then I get an error:

and the two times I tried, the .mtl file is empty each time. What am I doing wrong?

I installed the latest JRE before doing "java -jar cmc2OBJ-1.jar" - things seem to be running fine otherwise, but material export fails. Also, a temp directory is created in the export directory, and this directory seems to cause problems if I try to export again.

[StandingPadAnimations]

Looks like a bug with the JAR file. I'll upload a fixed copy as soon as possible

Does this program read in an exported OBJ? Or is the header just meant for downstream users?

cmc2OBJ is for reference. The idea is developers could compare their CommonMCOBJ header output with cmc2OBJ's output to make sure they're on the right path with implementing support

[StandingPadAnimations]

Uploaded the fixed JAR file on the release (as cmc2OBJ.jar, old one has been renamed to v1-cmc2OBJ-1.jar)

[erich666]

Fast work, thanks! This new version doesn't crash, but doesn't export materials into the OBJ file, if that is a goal of yours (I'm not clear on what all this version is supposed to do). I see faces in the .obj, but no material references.

[StandingPadAnimations]

I'll take a look at the material issues later today (I've been having some MTL issues on my end as well since I use PrismMC as my Minecraft launcher). Currently however, CommonMCOBJ doesn't have anything for materials (except whether textures are exported as one large texture atlas or seperate images), and the OBJ file contains all of the current CommonMCOBJ data

[StandingPadAnimations]

Ok once I've gotten cmc2OBJ to use my Minecraft JAR in Prism Launcher, the MTL contains all of the textures. Try manually adding the JAR (for the regular Minecraft launcher, .minecraft/versions to the resource pack settings and see if that helps:

[erich666]

I couldn't get your jar to export textures properly, but it's not vital (to me). I've done a quick implementation of CMC2OBJ in Mineways, download the beta. Please do give it a try and see if it's what you expect.

[StandingPadAnimations]

Looks good to me 👍

[mmdanggg2]

Yep, checked the values and they seem correct to me!

[erich666]

Thanks, both of you. Tomorrow I hope to release a new version of Mineways with this in it.

[erich666]

OK, released: https://github.com/erich666/Mineways/releases/tag/v11.07 - Mineways doesn't try to read these headers, just writes them at this point. If there's a reason for Mineways to read the header (I guess exports from other apps, like jmc2obj?), I'll add that. It's not a huge amount of work, but I wanted to get basic export going and let things settle down. Let me know when jmc2obj exports this type of header and I'll work on reading the data into Mineways.

[StandingPadAnimations]

Thanks for the cooperation, I've added Mineways to the list of exporters supporting CommonMCOBJ.

[erich666]

OK, I think this one can be closed.