SharpOcarina - Zelda OoT Scene Development System

[Jason777]

Help, when I download version 06 and extract the files, MapDev.exe quickly disappears.

Thank you!

 

Sounds like a weird problem that is not to do with the program, try a different extractor. Perhaps 7-Zip would be a good one.

[SanguinettiMods]

Do you have plans to implement Spinout's z64-tex-ext in SO?

[xdaniel]

Plans, yes, since spinout released the extension hack in fact, but I haven't implemented it so far. Also, development on most if not all of my projects has more or less stalled over the last few months, so I have no idea when I'll properly get back to SO or anything else. SO's source is out there tho, so if anyone wants to dive in and improve upon it, feel free to do so.

[Zeth Ryder]

Plans, yes, since spinout released the extension hack in fact, but I haven't implemented it so far. Also, development on most if not all of my projects has more or less stalled over the last few months, so I have no idea when I'll properly get back to SO or anything else. SO's source is out there tho, so if anyone wants to dive in and improve upon it, feel free to do so.

 

Wasn't there going to be a fix in SO that fixed the stretched textures that would randomly appear sometimes, like on the floor or walls that JSA was having?

[xdaniel]

Wasn't there going to be a fix in SO that fixed the stretched textures that would randomly appear sometimes, like on the floor or walls that JSA was having?

 

Well, last thing I heard about that is this:

 

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.

 

...plus I don't think we ever found surefire fix for this or I couldn't get anything like that implemented, so... well, I dunno.

[Arcaith]

One thing that has constantly frustrated me is the need to make extra textures for fades to black or white. Is there any chance you'll add support for vertex colour editing? Or perhaps add support for .x files in the near future so that vertex colours can be set beforehand in 3dsMax, Maya or Blender?

[xdaniel]

I... don't know. As in, I don't know if I'll add vertex color editing or .x file support. SO is a mess and difficult to work with - from a design standpoint alone already, basically meaning that I keep thinking "this is still group-based, but I want it material-based, this sucks" etc. -, SO's rewrite is stalled and I started it the wrong way (with the GUI as opposed to just getting it to work), so... no idea.

 

I did think about it earlier (maybe try and add en-/disabling of lighting on a per-group basis, maybe add a list of all vertices in the room that can be edited, but that would in turn mean having to store the vertices in the scene XML as .obj doesn't support vertex colors, etc., etc), but didn't come to a working, relatively simple to implement conclusion. I feel like I'd need to throw out most of SO and SO's current rewrite, and start over a third time, this time planning far, far ahead so as to not repeat the mistakes I've made so far...

 

EDIT: Hell, screw this, I'm gonna start planning for a 3rd rewrite tomorrow. Emphasis on planning - I'll read up on 3D graphics, lighting, the .obj format, probably the .x format as well, then make a sort of design doc with everything from the basic idea behind importing, creating N64 Display Lists, etc. down to class definitions. All this'll probably take a hell of a long time, especially once I get to the point where I have to start coding all this stuff, but it's worth it.

Edited April 27, 2012 by xdaniel

[Arcaith]

If you pop the design doc on Google Docs, I'll give you a hand with the planning. I'm sure there are a few areas my own knowledge can help with.

[Zeth Ryder]

There is something I would like to suggest in this rewrite for the future purposes, one of them being object sets for the map? (example young link era & adult link era) The other being

the option for changing the values for the skyboxes when enabled and the last thing is setting flow of time for the map.

[Rinku]

Wasn't there going to be a fix in SO that fixed the stretched textures that would randomly appear sometimes, like on the floor or walls that JSA was having?

 

I recently asked john smith account about his method to solve this problem in his Map Modelling thread, but he didn't answer. I hope it will be possible to solve it someday.

 

Good luck for your rewrite, xdaniel. You are very patient to do all this!

[spinout]

I... don't know. As in, I don't know if I'll add vertex color editing or .x file support. SO is a mess and difficult to work with - from a design standpoint alone already, basically meaning that I keep thinking "this is still group-based, but I want it material-based, this sucks" etc. -, SO's rewrite is stalled and I started it the wrong way (with the GUI as opposed to just getting it to work), so... no idea.

 

I did think about it earlier (maybe try and add en-/disabling of lighting on a per-group basis, maybe add a list of all vertices in the room that can be edited, but that would in turn mean having to store the vertices in the scene XML as .obj doesn't support vertex colors, etc., etc), but didn't come to a working, relatively simple to implement conclusion. I feel like I'd need to throw out most of SO and SO's current rewrite, and start over a third time, this time planning far, far ahead so as to not repeat the mistakes I've made so far...

 

EDIT: Hell, screw this, I'm gonna start planning for a 3rd rewrite tomorrow. Emphasis on planning - I'll read up on 3D graphics, lighting, the .obj format, probably the .x format as well, then make a sort of design doc with everything from the basic idea behind importing, creating N64 Display Lists, etc. down to class definitions. All this'll probably take a hell of a long time, especially once I get to the point where I have to start coding all this stuff, but it's worth it.

 

I don't know if it's possible to use C libraries in C#, but if so I think libobj would be a good place to start, especially now that the [working] functions can segregate by whatever means you want - that is, organize by mesh, group, object, smoothing group, whatever. And I'm sure you would have useful contributions to backport to the library if you did use it. In regards to libobj n64 mesh generation, I'm working on a separate library which will do texture conversion, because as of current it only does 5551 non-CI. Of course, the active version of libobj isn't the main libobj repository; the main libobj repository is still compatible with z64anim whereas the new one requires libmem32. I don't know how well applications end up being with libmem32, I haven't implemented it in z64anim yet.

 

Sorry for going off topic [ and into my own software ], carry on...

[Rinku]

Polygon types don't seem to be working anymore in SharpOcarina...

 

So I will have to wait until I can continue my project.

[Jason777]

Polygon types don't seem to be working anymore in SharpOcarina...

 

So I will have to wait until I can continue my project.

 

Oi, I'm making a silly little console program for that.

[john_smith_account]

I recently asked john smith account about his method to solve this problem in his Map Modelling thread, but he didn't answer. I hope it will be possible to solve it someday.

 

Good luck for your rewrite, xdaniel. You are very patient to do all this!

 

Sorry I couldn't respond, my life kinda sucks right now.

 

XDaniel's post of the short expalinsion of the fix is about all I've done. I completely understand the problem, and this fix is the best you can do.

 

The UV size *IS* the problem. Anything you did in Sharp Ocarina it's self to fix it would acutally be incorrect. The correct solution, and probably the way nintendo handled it, would be to restain the UV size within the modeling software used to design the levels. That is not an option here obviously, since we didn't design the modeling software we use, and can't modify it.

 

I personally would rather Sharp Ocarina not implament any "cheap" fixes.

 

Following my tip for Google Scetchup, starting any room design at 0,0,0 and then making it a group before moving it works wonders. A little simple math, and a guide line pluggin an I can assure you your design will come out error free 100% of the time.

 

It's not an error in Sharp Ocarina, it's just a limit in the N64 map format. As is the preview funtion lets you see if the error is present. An error warning could be added for building the map, alerting you to the error but allowing you to ingore it if you want.

 

But I can't think of a correct way to fix it in SO. And I'm oppose to an incorrect fix.

[Arcaith]

I would really urge people to learn to use at least Blender rather than SketchUp, since it has a proper UV editor. If you can get your hands on a copy of 3dsMax or Maya, I preference both of those above Blender, but for this kind of work anything is better than SketchUp.

 

There is another option, though. You can make the model and texture it in SketchUp and then edit the UVs in Blender or any other program that has a UV modifier. You'll probably get a far more correct obj output from Blender, too.

[Zeth Ryder]

Sorry I couldn't respond, my life kinda sucks right now.

 

XDaniel's post of the short expalinsion of the fix is about all I've done. I completely understand the problem, and this fix is the best you can do.

 

The UV size *IS* the problem. Anything you did in Sharp Ocarina it's self to fix it would acutally be incorrect. The correct solution, and probably the way nintendo handled it, would be to restain the UV size within the modeling software used to design the levels. That is not an option here obviously, since we didn't design the modeling software we use, and can't modify it.

 

I personally would rather Sharp Ocarina not implament any "cheap" fixes.

 

Following my tip for Google Scetchup, starting any room design at 0,0,0 and then making it a group before moving it works wonders. A little simple math, and a guide line pluggin an I can assure you your design will come out error free 100% of the time.

 

It's not an error in Sharp Ocarina, it's just a limit in the N64 map format. As is the preview funtion lets you see if the error is present. An error warning could be added for building the map, alerting you to the error but allowing you to ingore it if you want.

 

But I can't think of a correct way to fix it in SO. And I'm oppose to an incorrect fix.

 

Nintendo didn't restrain UV size in the program though, as far as I'm aware of Max has no such functions which is what they were using(3DS MAX Kinetics before they became part of autodesk).

I also don't believe "your UV size is wrong is the answer" there is something else going on cause I'm using the same size UV mapping on other objects or sides of faces and getting correct stuff where one of them fucks up. I try rebuilding that face entirely and remapping the UV, same issue. I'm beginning to think it might be a #Ocarina glitch.

Like the mapping on one of my pillars gets messed up entirely and gets put horizontal for the mapping when the texture is set for vertical!

[Arcaith]

Max doesn't have a restrain UV function, no. But a lot of the UVs on the model you sent me were over 100 on the U axis, and 16 on the V axis. Shifting them back closer to the origin fixed a lot of the errors, the remainder I see at the moment were outlying verticies that I didn't notice.

[Zeth Ryder]

Max doesn't have a restrain UV function, no. But a lot of the UVs on the model you sent me were over 100 on the U axis, and 16 on the V axis. Shifting them back closer to the origin fixed a lot of the errors, the remainder I see at the moment were outlying verticies that I didn't notice.

 

So what is the max size allowed for the UV?

[john_smith_account]

Nintendo didn't restrain UV size in the program though, as far as I'm aware of Max has no such functions which is what they were using(3DS MAX Kinetics before they became part of autodesk).

I also don't believe "your UV size is wrong is the answer" there is something else going on cause I'm using the same size UV mapping on other objects or sides of faces and getting correct stuff where one of them fucks up. I try rebuilding that face entirely and remapping the UV, same issue. I'm beginning to think it might be a #Ocarina glitch.

Like the mapping on one of my pillars gets messed up entirely and gets put horizontal for the mapping when the texture is set for vertical!

 

 

I completely understand the problem to the point where I can build maps which are 100% glitch free.

 

 

I've explained it before, probably earlier in this topic. I made a demo, I thought proved the theory, but I'm obviously having trouble communicating the idea. I hope XDaniel can hop on some time and put the answer into language that makes sense.

 

 

The problem isn't simply that the UV value gets too big, it's when a UV value reaches a "wrap around" point.

 

 

These values are in no way correct, but I hope they explain the principle.

 

 

Imagine the UV mapping for a give size can go from -100 up to +100. Simple enough, keep the UV above -100, and below 100, and it should come out correct, right?

 

Wrong. You can image the UV range as a repeating grid of the same texture. That is at any given size, after you reach the limit of the UV size there is a point at which the mapping starts over again. The errors occur when you cross that invisible boarder.

 

If the left side mapping starts at +95, and the UV is 10,10 then the value given an infinite mapping would be +105. But since the value is not infinite, it wraps around staring back at -100, and thus become -95. So the texture stretches back to -95 and looks messed up.

 

You can make you UV's as small(or is it large?) as you like trying to combat the error. Eventually if the level is large enough you will cross that invisible line.

 

And worse still, how big that grid is differnt for each size mapping.

 

Want proof? Make some squares in sketchup. Make one, then another beside it, then another. Keep repeating them. Then paint them, one by one with the same UV value on the texture. Create another line of squares below it. And repeat, and repeat. You'll find as long as you keep the same UV the error will occur at a fixed interval.

 

It's hard to see the pattern at first if you start at 0,0 since the UV mappings start back some where in the negative values, but after you get the first error, all errors there after will repeat at the same distance.

 

That you I start each room at 0,0 and then make it a group. In sketchup, the UV mapping is fixed on where you made the selected faces into a group. It's not a fool proof system, but it works well.

 

I hope someone can make sense of this. I'm not wrong, I just don't know how to explain it.

[Zeth Ryder]

it still doesn't explain my pillar UV mapping going from vertical to horizontal. D:

Like literally the texture was rotated 90 degrees.

[Arcaith]

Because of the overflow, the vertex order likely changed and rotated the orientation of the mapping. It can happen.

[Zeth Ryder]

Because of the overflow, the vertex order likely changed and rotated the orientation of the mapping. It can happen.

 

Weird what that overflow can do o.o

[Rinku]

Sorry I couldn't respond, my life kinda sucks right now.

 

XDaniel's post of the short expalinsion of the fix is about all I've done. I completely understand the problem, and this fix is the best you can do.

 

The UV size *IS* the problem. Anything you did in Sharp Ocarina it's self to fix it would acutally be incorrect. The correct solution, and probably the way nintendo handled it, would be to restain the UV size within the modeling software used to design the levels. That is not an option here obviously, since we didn't design the modeling software we use, and can't modify it.

 

I personally would rather Sharp Ocarina not implament any "cheap" fixes.

 

Following my tip for Google Scetchup, starting any room design at 0,0,0 and then making it a group before moving it works wonders. A little simple math, and a guide line pluggin an I can assure you your design will come out error free 100% of the time.

 

It's not an error in Sharp Ocarina, it's just a limit in the N64 map format. As is the preview funtion lets you see if the error is present. An error warning could be added for building the map, alerting you to the error but allowing you to ingore it if you want.

 

But I can't think of a correct way to fix it in SO. And I'm oppose to an incorrect fix.

 

Thank you! So, you basically make one square at 0,0,0, make it a group and then you can move it as you like and proceed normally? You once said it were even possible to fix a model instead of making a new one...how would you do that?

 

 

 

To my problem with the polygon types not working:

 

Oi, I'm making a silly little console program for that.

 

I found the problem, it's because my collision model doesn't have any groups. See, the group names of the collision model have to match up with the group names of the rooms. But I can't name groups in Sketchup, I think. Sketchup outputs more groups than I make, too. So it's impossible for them to match up.

[john_smith_account]

To my problem with the polygon types not working:

 

 

 

I found the problem, it's because my collision model doesn't have any groups. See, the group names of the collision model have to match up with the group names of the rooms. But I can't name groups in Sketchup, I think. Sketchup outputs more groups than I make, too. So it's impossible for them to match up.

 

I understand why in earlier versions Sharp Ocarina as the ideas were being fleshed out why the rooms had to match, but I always expected that to change in later versions.

 

I 100% support texture to collision system. But why match them to the room file textures? Why isn't collision matched to the collision .obj textures?

 

Why is it still matched this way? You have to choose a seprate .obj for collision anyways, so why arn't collision types matched to the textures of the collision .obj instead?

 

I'm guessing everyone works around this in a similar fashion:

 

1. Complete the finished rooms map first.

2. Combine all the rooms to make a collision map.

3. Open the combined .obj in Sharp Ocarina as the collision map.

4. Open the same combined .obj in Sharp Ocarina as a room.

5. Map the collisions, and Save an .xml

6. Build the collision map

7. Manually Dump the .zscene

8. Build the .zmap in Sharp Ocarina from the seprate rooms maps, collision will not match but...

9. Replace the .zscene generated by the seprate rooms build with the one made in step 7.

10. Manually add the room offsets.

 

Now I'm not dissing Sharp Ocarina, I'm VERY VERY happy with it. I LOVE texture mapping the collisions too! It's simple, and works great. I just think it's better done if the .zscene .obj is completely independent of the .zmap .obj.

[xdaniel]

Yeah, the collision model room model group matching is junk and a shitty workaround for oversights I made during coding, also see this note in the source here. I realize what crap this is and intend to fix it, but not in the current SO because it would mean throwing part of it out, rewriting that, while leaving all the other, unrelated crap in. The planning stages for the total rewrite, with the design doc and all, are in progress and this group name crap is one thing ruled out, or verboten if you want, from the start.