xdaniel Posted February 6, 2012 Author Share Posted February 6, 2012 "Alright, that looks good. Hope this'll import correctly, let's see the approximation..." "Oh crap, the texture coordinates got messed up! Gotta fix that before the actual import..." The above screenshot = SayakaGL's Ucode interpreter implemented in SO. Seeing how it needs to reinterpret the Display Lists after each and every change to them, it automatically disables itself whenever you try to change something (or technically, whenever the GL control or the "Simulate N64 Graphics" checkbox loses focus). Just switch it on before you want to make your actual import, then fly around the scene to check for ex. broken texture coords. Link to comment Share on other sites More sharing options...
Okami Amaterasu Posted February 8, 2012 Share Posted February 8, 2012 Is there a way you could have something like being able to manually edit the lighting? Currently SharpOcarina generates the lighting in maps, but I think being able to manually do it would be useful sometimes. Link to comment Share on other sites More sharing options...
john_smith_account Posted February 8, 2012 Share Posted February 8, 2012 APPLAUDS Looking good XDaniel. Link to comment Share on other sites More sharing options...
Zeth Ryder Posted February 9, 2012 Share Posted February 9, 2012 What's causing the broken texture coordinates? Link to comment Share on other sites More sharing options...
xdaniel Posted February 9, 2012 Author Share Posted February 9, 2012 What's causing the broken texture coordinates? From JSA's thread in Q&A about the problem, which was the final impulse for me to implement the improved preview: If you're encountering what I think you do, then it's the limited precision of texture coordinates on the N64... it's late and I'm not at my PC, but if I recall, N64-side texture coords are signed 16-bit values which will overflow/wraparound if the original value from the .obj model is out of range - that results in extremely stretched/warped texture mapping. Link to comment Share on other sites More sharing options...
spinout Posted February 10, 2012 Share Posted February 10, 2012 From JSA's thread in Q&A about the problem, which was the final impulse for me to implement the improved preview: ₪ xdaniel'" data-cid="18773" data-time="1328228894"> If you're encountering what I think you do, then it's the limited precision of texture coordinates on the N64... it's late and I'm not at my PC, but if I recall, N64-side texture coords are signed 16-bit values which will overflow/wraparound if the original value from the .obj model is out of range - that results in extremely stretched/warped texture mapping. You know, I think that the coordinates are being converted wrong, as the texture can be corrected as JSA said. A few test cases are surely needed. Link to comment Share on other sites More sharing options...
xdaniel Posted February 10, 2012 Author Share Posted February 10, 2012 You know, I think that the coordinates are being converted wrong, as the texture can be corrected as JSA said. A few test cases are surely needed. I did just fix a problem with the conversion of normals (boiled down to a signedness issue, I believe) which resulted in overly dark maps in-game when lighting was enabled, so it might very well be that my formula's wrong. Although I still believe that that, if it's the case, isn't the only problem... Link to comment Share on other sites More sharing options...
john_smith_account Posted February 11, 2012 Share Posted February 11, 2012 You know, I think that the coordinates are being converted wrong, as the texture can be corrected as JSA said. A few test cases are surely needed. XDaniel, I'll get you some solid data on corrected UV, versus the orginal UV. It will be Monday at the earliest, but it will save you the trouble of finding the sample data yourself. Link to comment Share on other sites More sharing options...
john_smith_account Posted February 13, 2012 Share Posted February 13, 2012 I believe I've found the problem in my maps. I'm posting this publicly on the hopes that if I'm not clear, at least someone might get the jest of what I'm saying. SharpOcarina's 3D preview is not representative of how it's going to look like in-game. It's just an .obj viewer and does not read back and interpret the Display Lists it generates, although I'm starting to think I should implement this in the current SO too, not just the rewrite if I ever get there... If you're encountering what I think you do, then it's the limited precision of texture coordinates on the N64... it's late and I'm not at my PC, but if I recall, N64-side texture coords are signed 16-bit values which will overflow/wraparound if the original value from the .obj model is out of range - that results in extremely stretched/warped texture mapping. I don't really have much of an idea what to do against this, besides making sure that triangles aren't too big, textures don't repeat across it too often, things like that. Although that didn't always work for me... The first(may not be the only) problem is related. It is related to the overflow, but it's probably not what you think it is. I do understand it thoroughly, but may not be able to explain it clearly based on my limited understanding of how you correct the values outside the n64's UV range within SO. Here's my educated guess based on testing. The problem I'm getting isn't from a texture scaled too large, it has to do with the starting and ending ranges of the UV values on a given vertex. Here's what happens. SO seems to somehow correct the values outside the 16-bit signed range(-32768 to 32767). So you can have a vertex with crazy UV's like 120,000,112,000 or similar, and the gets corrected just fine. The problem only seems to occur when you have a vertex that starts within the valid range16-bit range (-32768 to 32767) connected to a vertex(forming a poly) with a corrected(wrapped around?) value. Totally made up numbers but to try to convey the point a poly formed with vertexes having the UV's: 120,000,112,000 and 120,000,112,000 and 110,000,112,000 but a poly with: 30,000 , 30,000 and 30,000 , 30,000 and 33,000 , 33,000 Since it starts in one range, and crosses the wrap around. Yes my UV numbers in the example ARE BS, but I'm just trying to make the point that connected UV values across the "wrap around" value is the definite cause of errors in my maps. (Using TIG's exporter anyways.) Irony: I can't think of an automated solution. It's more a matter of incompatibility between n64's 16-bit mapping and .obj's "infinite?" UV value. It may be better handled by rewriting the .OBJ exporter than adding a fix in SO, I dunno. Conceivably, you could have a check system that catches poly UV's that criss-cross the boundaries by bring the start and finish into a valid range. That is, like in the above example: 30,000 , 30,000 and 30,000 , 33,000 and 33,000 , 33,000 Subtract the lowest value eliminating the crossing of the wrap around: 0 , 0 and 0 , 3,000 and 3,000 , 3,000 It will appear much more neat on looking in game than the wrap around error. At least the UV scaling will be correct. It will work very well on repeating patterns. But it's not technically correct since it won't preserve the the actual UV staring and ending values. Not to mention it will require coding, and may be a hassle for a "fun" project. Still it's a possible solution. If you implement it, may I subject it be added with a option check box. Something along the lines of "Apply wrap around fix"? Then again, maybe I'm the only one getting this error. If you need some real examples, just need me to re-explain the issue, or just think I'm wrong let me know. Link to comment Share on other sites More sharing options...
SanguinettiMods Posted February 13, 2012 Share Posted February 13, 2012 Just a random idea... You know how Adobe Photoshop has an Angle Controller for Shadow effects and such? Perhaps you could go about implementing something like this into SharpOcarina, it would set a light source angle for Vertex Normals to start getting generated at, so it would look like, if you happened to model something like a building or a tree, it would look like there is a Shadow Cast on the Ground. Link to comment Share on other sites More sharing options...
Arcaith Posted February 14, 2012 Share Posted February 14, 2012 JSA, I believe that's what xdan was saying. The cause being UV co-ordinates being too large for the engine to handle causing wraparound. I've never had this problem myself since I try to keep my UV's bounded between -10 and 10 on either axis. Also, I am 100 percent in favour of an angle controller for normals calculation. Link to comment Share on other sites More sharing options...
DeathBasket Posted February 14, 2012 Share Posted February 14, 2012 I don't know anything about what exactly vertex normals are or do but by definition a normal can only take one direction - perpendicular to the plane it is normal to. If this is not the case with vertex normals then calling them such does not really make any sense. Disregard this if I've completely missed the point. Link to comment Share on other sites More sharing options...
john_smith_account Posted February 14, 2012 Share Posted February 14, 2012 JSA, I believe that's what xdan was saying. The cause being UV co-ordinates being too large for the engine to handle causing wraparound. I've never had this problem myself since I try to keep my UV's bounded between -10 and 10 on either axis. Also, I am 100 percent in favour of an angle controller for normals calculation. ₪ john_smith_account'" data-cid="18954" data-time="1329172467">It is related to the overflow, but it's probably not what you think it is. It's a different problem than the UV's simply being too large. That was the entire point of my post. The errors in my maps seems to be cause by polygons crossing UV boundaries, as described above. PLACEHOLDER: *Sigh*, fine I'll be back with solid data. Guess I need an example. http://www.2shared.c...mF5Y/ERROR.html Sorry about the crappy file host, I'm on the library's WIFI. I'll start with an error free entry from the OBJ. You'll notice I repeated the same texture UV's a few times to prove the error isn't in the UV size. To really drive the point home, I made a somewhat ridiculus mapping on the first poly. All examples were prepared using TIG's exporter with the x1000 modification. You can find it at the start of the Map Modeling Tips Topic. g ERROR_Main-BIG1 usemtl BIG1 v 1000.0 0.0 1000.0 v 0.0 0.0 0.0 v 0.0 0.0 1000.0 v 1000.0 0.0 0.0 vn 0.000000 1.000000 0.000000 vn 0.000000 1.000000 0.000000 vn 0.000000 1.000000 0.000000 vn 0.000000 1.000000 0.000000 vt 1.000000 -1.000000 vt 0.000000 0.000000 vt 0.000000 -1.000000 vt 1.000000 0.000000 f 122/122/122 123/123/123 124/124/124 f 123/123/123 122/122/122 125/125/125 Now I may not have this exactly right, but UV's get multiplied up to values the N64 can use. So Sharp Ocarina's numbers will be something like: vt 10,000 -10,000 vt 0 0 vt 0 -10,000 vt 10,000 0 You can open the SketchUp file and see it for yourself HUGE UV's no errors. Now my math my be off, but you should be able to see what I'm getting at. The UV mappings only have a 16-bit signed range(-32768 to 32767). After that, they "wrap around" back to -32768 (or is it 0?, Xdaniel a little help.) The type of "random" errors I was getting was not from the UV mapping being too big, it was because it crossed the wrap around. As showen with the mapping for material BIG1, you can have large mappings without errors. If I'm correct, any mapping has values that cross 32767, 98302, 163837 and -32767, -98302, -163837 will get errors. That is you're fine as long as you start and finish your mapping within these ranges, but even a modest UV mapping will get messed by starting on one side, and connected to the other side of these bounderies. Now, let get right to errors. I'm not going to bother working the math on the UV's. I don't understand the conversion really, but I'm sure I understand the problem. If I'm in error on any point, feel free to correct me. g ERROR_Main-ERROR3 usemtl ERROR3 vt 10.000000 -100.000000 vt 0.000000 -90.000000 vt 0.000000 -100.000000 vt 10.000000 -90.000000 g ERROR_Main-ERROR2 usemtl ERROR2 vt 96.000000 -20.000000 vt 95.000000 -10.000000 vt 95.000000 -20.000000 vt 96.000000 -10.000000 g ERROR_Main-ERROR1 usemtl ERROR1 vt 91.000000 -10.000000 vt 90.000000 0.000000 vt 90.000000 -10.000000 vt 100.000000 0.000000 vt 92.000000 -10.000000 vt 93.000000 -10.000000 vt 94.000000 -10.000000 vt 95.000000 -10.000000 vt 96.000000 -10.000000 vt 97.000000 -10.000000 vt 98.000000 -10.000000 vt 99.000000 -10.000000 vt 100.000000 -10.000000 I'd really have to know more about UV's and SharpOcarina to be any more help. Sorry. Xdaniel, good luck. Link to comment Share on other sites More sharing options...
xdaniel Posted February 14, 2012 Author Share Posted February 14, 2012 Xdaniel, good luck. That I'll probably need, yeah... Definitely thanks for your explanations and the test case, tho. Not much else to say right now; I'll see what I can do. Link to comment Share on other sites More sharing options...
Arcaith Posted February 16, 2012 Share Posted February 16, 2012 That's what I meant, the UV's were going outside the range that the engine uses. Between -10 and 10 seems to be fine in most cases, and since that's tiling the image 20 times in total, I can't really see many scenarios where it's going to be a problem. I think though that people really need to start moving away from SketchUp, since you can't fix gigantic mappings per face easily in that. With a proper UV editor, you can break some of the faces from the main set and offset them by whole number UV co-ordinates so that the edges of the two pieces still line up. Very useful for irregularly shaped edges. Link to comment Share on other sites More sharing options...
Secant Posted February 16, 2012 Share Posted February 16, 2012 I think though that people really need to start moving away from SketchUp, since you can't fix gigantic mappings per face easily in that. With a proper UV editor, you can break some of the faces from the main set and offset them by whole number UV co-ordinates so that the edges of the two pieces still line up. Very useful for irregularly shaped edges. I agree with a proper UV editor. Trouble is, SketchUp is wonderfully easy for building low-detail dungeons and landscapes, and is also free (for those slightly less pirate-inclined); you can build a decently-sized low-detail dungeon in about 3 hours with plans already laid out. I am still convinced there is a plugin for SketchUp somewhere out there that allows texture mapping as precise as 3DS Max, though. Link to comment Share on other sites More sharing options...
Arcaith Posted February 16, 2012 Share Posted February 16, 2012 Blender isn't too bad if you take the time to learn its interface, and that is most definitely free :3 Link to comment Share on other sites More sharing options...
john_smith_account Posted February 17, 2012 Share Posted February 17, 2012 RETRACTION Ok, I'm eating my words here. Though a cheap UV fix would be helpful for ease of use, I'm starting to think it isn't work the effort of coding... It might be good for newcomers, but... I may have a fix allready, so... I'm sorry for the trouble. *walks away quietly* Link to comment Share on other sites More sharing options...
john_smith_account Posted February 18, 2012 Share Posted February 18, 2012 And, proper technique solves all my UV errors so far! The UV errors I was getting seem to be avoidable in Sketchup by following some simple rules in modeling. You can even fix old maps. Mind you it is harder to fix a map after the fact, but it's still not that hard to do. Here's my new method for modeling in SketchUp: 1. Make a rectangle at the 0,0,0 axis. 2. Make the rectangle a group. 3. If you're making a dungeon or other multiple map scene, move the rectangle(group) to were you wish to start modeling a room. Why does it work? My guess is that UV's, and maybe coordinates with the groups are relative to where the selected polygons were initially made into a group. I really haven't tested enough to know for sure though. I based this method entirely on observing how OZMAV handled dumping maps from the game to .obj format. Forgive me if this should have been obvious, and correct me if I'm wrong in any points. If this proves out, I'll refine the method and post it in the modeling tips topic. Link to comment Share on other sites More sharing options...
Rinku Posted February 28, 2012 Share Posted February 28, 2012 Help, when I download version 06 and extract the files, MapDev.exe quickly disappears. Thank you! Link to comment Share on other sites More sharing options...
xdaniel Posted February 28, 2012 Author Share Posted February 28, 2012 Help, when I download version 06 and extract the files, MapDev.exe quickly disappears. Thank you! As in, MapDev.exe disappears from the folder you extracted the files to? That might be your anti-virus software overreacting, can't say for sure. Try disabling it before extracting, then re-enable it and try to start SO. If your anti-virus starts complaining, or if MapDev.exe disappears again, that's likely the problem. Link to comment Share on other sites More sharing options...
Rinku Posted February 28, 2012 Share Posted February 28, 2012 Thank you! I thought it couldn't have been my anti-virus because it SHOULD ask me before deleting files. And guess, it was my anti-virus. Luckily, it didn't try to delete the file nor complained when I opened it after having extracted it with disabled anti-virus and then having re-enabled it. Well, the new version of this anti-virus software seems to do to its liking... It's time to examine version 06 of SharpOcarina! Link to comment Share on other sites More sharing options...
Xylaphone Posted February 28, 2012 Share Posted February 28, 2012 (edited) Does SO include MM actors in the program? I'm also trying to get this up and running on crossover but I haven't had success yet Edited February 28, 2012 by cdogwashere Link to comment Share on other sites More sharing options...
Secant Posted February 28, 2012 Share Posted February 28, 2012 SharpOcarina isn't compatible with Majora's Mask or any of its resources. This program deals solely with the Debug ROM for OoT. Link to comment Share on other sites More sharing options...
Xylaphone Posted February 28, 2012 Share Posted February 28, 2012 SharpOcarina isn't compatible with Majora's Mask or any of its resources. This program deals solely with the Debug ROM for OoT. cool, I guessed that but I wasn't 100% sure so I wanted to get clarification Link to comment Share on other sites More sharing options...
Recommended Posts