Jump to content

briclabs

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by briclabs

  1. Still fiddling, but I don't think most of the typical JSON flags work when applied to OBJ files. I think the reason is that things like coords for the UV textures are actually part of the OBJ file itself, and therefore get overriden. Since a typical JSON file just deals with code-generated blocks, I don't think they have this hardcoded limitation. For example, so far I now need a separate model, with appropriate UV coords, just to define a block that's upside down, since the faces on the side of the block have to be rotated 180 degrees to avoid the issue in my previous screenshot. That works. However I then discovered that I'll need an additional OBJ model for north/south, east/west, since the top and bottom faces would need their UV coords changed to match what the vanilla blocks' textures are. I looked at the OBJ file format and did some experimenting, and there's no way to uncouple the UV mapping from the model; doing so results in invisible faces. Therefore I don't think OBJ is a suitable pursuit for this project, as it is too encumbered by having to have static files define every detail. While I haven't looked into trying to implement a custom OBJloader / OBJmodel, I suspect that as long as I'm using static OBJ files, I'm going to be stuck making a mess-load of them just to do basic orientation of the textures applied to each face. I'm probably going to abandon this pursuit, but I'll see if there's a way to generate a non-cubic model in Java, instead of using static OBJ files. Working in Java would be significantly more flexible I'd expect, since by nature static files don't have as much accessibility to the code (and basically, if it did, it would be an override in the code anyway). I'll mark this thread resolved since the original issue was resolved (thank you!) but I think OBJ files for non-cubic shapes are too cumbersome for what I'm trying to accomplish.
  2. Well... significant progress. I think the moral of the story here is that one should not try and do a Blender custom model unless they actually put the texture in first, and then align it using the steps I had in my previous post so that its correctly laid out. Seems the UV orientation is contained in the OBJ data. Unfortunately OBJ syntax feels more like machine code rather than meant-for-a-human-to-write-manually, so I couldn't begin to guess at the differences. It also appears, as can be seen in my screenshot below, that stairs are literally upside-down blocks, which is why the texture is likewise also upside-down, hence the lines in the oak planks texture not lining up. So it appears I'll need an additional model just for that variant, since the model determines the UV orientation, and that determines the orientation of the textures. And my MTL file, fyi, is still just this simple, so it could point at any existing texture. I wanted to make sure I did it this way so that texture packs that replace vanilla textures would automatically apply here as well. # Blender MTL File: 'fortyfive.blend' # Material Count: 1 newmtl fortyfive map_Kd minecraft:block/oak_planks Unfortunately unless I can figure out how to assign the actual texture image file to the model dynamically in the Java code, I think I'm going to abort much more work on this mod attempt. I wanted to introduce diagonal blocks of all applicable material types (stone, quartz, etc) but I haven't found any examples where this has been done. The model would stay the same, but the image used for the texture would be changed. I'm not excited about making several hundred JSON -> OBJ -> MTL file sets just to accomplish that. Seems like there should be a simpler way of using the same JSON -> OBJ file chain and assigning the MTL within Java instead of a static file.
  3. Seems like its something with the OBJ model itself. In blender, I just did the following: Showed the UV Editing window. Noted that the UV map presented was an unfolded version of my object. Changed to Edit Mode. Changed select mode to Face Select mode. Selected each face of my model one at a time, right-clicked and chose "UV Unwrap Faces -> Unwrap". Noted in the UV window, the map presented was now a single square, with each face overlapping on said square. I have the scale correct now, and my mtl file still just has to look like this (none of the extra lines Blender added during export were needed): # Blender MTL File: 'fortyfive.blend' # Material Count: 1 newmtl fortyfive map_Kd minecraft:block/oak_planks The item model is still showing the bad scaling for the texture, but that's because I hadn't applied the new OBJ file to that yet, just to the block. I'm going to continue fiddling with (read: learning) Blender to now figure out how to get the faces' textures to have the correct orientation. Will continue to post for the benefit of anyone else that runs into this issue.
  4. I think you're probably right; I didn't think of that. It seems to make sense given the way its rendering that its using the default texture as a single square texture to apply to all faces at the same time. I'll see if I can figure out how to have it apply to each face like a normal block. I'll also look at the example you gave (thank you!) and see if that gives me any leads.
  5. Greetings, I have been working on developing my first mod. It involves loading an OBJ file as a model for a block that extends the StairsBlock class, so it has the same capabilities as stairs in terms of placement and shape, etc. In the OBJ file, it points at an MTL file. In the MTL file, I'm indicating: map_Kd minecraft:block/oak_planks It correctly finds the texture and applies it. The model renders just fine and is the right scale. However, the texture itself is scaled far too large, so a single pixel in the normal texture now takes 1/4 of the block. I've read that with wavelength mtl files one can set the scale for the texture by using "-s x y z" but that doesn't seem to get honored in this case. I'm suspecting that is not supported in Minecraft Forge as a way of rescaling textures. The block model itself is the perfect size, so why is the texture rendering at the wrong scale? Anyone have thoughts as to what I could be doing wrong or things I can try? Thanks, ~ Bric
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.