SharpOcarina - Zelda OoT Scene Development System

[Rinku]

By the way, it would be very helpful if SharpOcarina didn't expect the models, the .xml scene and the rom to be in the same file/directory.

[Arcaith]

It doesn't. It's just the demo's xml file that does that. I think he moved it all into the 'demo' folder after testing it, so the file paths in that file are bad. I'll probably provide a new demo dungeon for the new version anyway, something that's a bit bigger and more fun for new map builders to play with.

[Rinku]

I'm not using the demo's .xml file but SharpOcarina expects everything to be in the same directory. By the way, I'm using version 06.

 

I'm looking forward to a new demo dungeon from you! It sure will be great for new map designers!

[Arcaith]

That's odd. I have all my xml files in the program root and all the obj and texture files in their own folders.

[xdaniel]

Status update time, tho there's not much to report...

 

The design document for SO #3 takes quite a while to write. Well, obviously it's not exactly the writing itself, but thinking everything through and such. In fact, I'm only two and a half pages in yet. Wavefront .obj and .mtl command support has been determined, the SO internal structure of scenes and rooms has been as well (with things like support for alternate object sets being part of the planning) , I've written down some random related ideas that may or may not influence SO as well.

 

I am still far from finished with this, so it's of course also still a long way until actual coding can start. I really want to not dive in head first yet again, like I did with pretty much every other project so far. And we've seen how bloody well that worked out with SO, haven't we?

 

I'll send the doc out to some people, who I think would be able give useful feedback and so on, once it's grown by another 5 pages or so... and please don't ask for it, I'm already rather sure about who I'll ask for feedback.

[Okami Amaterasu]

I do have a couple suggestions on some things that I thought could work a little better for time saving. Maybe have a way to select a number of groups and have the same settings applied to them all at once, so you don't have to go through a huge number of them to make the same change, and maybe a ay to collapse said groups into folder type things in the program to save space and stuff. I had some others too, but I can't remember them right at this moment, if I do I'll edit this.

[Forecast]

Sorry to revive this thread, but I have a small suggestion myself; Is it possible to add a "Climb Down" option alongside the other options in the "Collision & Exits" tab? To elaborate on this: I am aware of the "Ladder-type Climbing" option, but it seems to only climb up after you reach the top when you try to climb back down.

[Jason777]

Sorry to revive this thread, but I have a small suggestion myself; Is it possible to add a "Climb Down" option alongside the other options in the "Collision & Exits" tab? To elaborate on this: I am aware of the "Ladder-type Climbing" option, but it seems to only climb up after you reach the top when you try to climb back down.

 

Answer:

Click the part that will be climbed down from now and edit its collision. You'll be doing the same, but editing the "Flags" to be this documentation:

When setting the flags for the collision for the part that is used for climbing down (in UoT), set the flags to 0x0060, 0x000B, 0x0000, and 0x0FC, respectively.

 

^^ Taken from this page: https://sites.google.com/site/flotonic65/modding/n64zeldatut/customcollisionincustommaps

 

Basically, here is the polygon type definition to climb down:

0060000B00000FC

To construct a ladder correctly... : https://sites.google.com/site/flotonic65/modding/n64zeldadoc/modelpresets#Ladder

 

Credit goes to Flotonic.

[Forecast]

Answer:

 

 

^^ Taken from this page: https://sites.google...ionincustommaps

 

Basically, here is the polygon type definition to climb down:

-code-

 

To construct a ladder correctly... : https://sites.google...lpresets#Ladder

 

Credit goes to Flotonic.

Oh, thanks Jason I was just making a simple suggestion for those who do have trouble with that sort of thing, but thanks anyways.

[Griduser64]

nvrm

[Jason777]

So I tried importing a map with SharpOcarina today and found a few errors with the vertex color (normal?) calculation. Thank god I'm not getting UV out of range errors, but those vertex normals are quite noticeable... Especially when the sun rises, sets, or it is nighttime. It may just be that I've triangulated the hell out of that map, but I figured I should give you a look, xdaniel:

 

(There are a lot of images, so I put it in a spoiler tag...)

 

 

 

There were more pictures, but I think you get the point.

 

 

 

Is there an option to disable normals? I know that Obj2Area had the option and that would probably be of the most help to me.

[xdaniel]

I knew my normal calculations were pretty bad, but those are probably the most severe glitches I've seen so far... Anyway, any scene that's designated as outdoors in SO will have normals enabled, which'll also influence other settings (skybox, time flow, etc.) There's no option to enable or disable just the vertex normals, either, so you'll need to set the scene to indoors, then manually change the header to enable ex. the skybox.

[Jason777]

I knew my normal calculations were pretty bad, but those are probably the most severe glitches I've seen so far... Anyway, any scene that's designated as outdoors in SO will have normals enabled, which'll also influence other settings (skybox, time flow, etc.) There's no option to enable or disable just the vertex normals, either, so you'll need to set the scene to indoors, then manually change the header to enable ex. the skybox.

 

Ah, my map is has a lot of weird "broken" polygons in it anyways, so I doubt your normals calculation is entirely to blame. Thanks for the info, xdaniel, it works perfectly.

[DeathBasket]

Could be the normals. I get this a lot too and my maps don't have 'broken' polygons. What version of SharpOcarina are you using? From what I can tell by looking at the source here they do not seem to be correct. I am not sure about that though; I don't know if the normals have been changed since being read from the object file but since they are signed numbers should they not be multiplied by 127?

 

EDIT: Yep, that seems to make my map look a lot nicer. For comparison:

 

 

 

 

 

Note: the first screenshot was from an old version where textures were still darkened, sorry... Still, these were both near enough the same time of day so you should be able to notice the difference in shading; the second image looks a lot more natural.

Edited August 23, 2012 by DeathBasket

[Zeth Ryder]

Yeah, this is the same problem I've been having as well, that second pic looks much better!

[Jason777]

Could be the normals. I get this a lot too and my maps don't have 'broken' polygons. What version of SharpOcarina are you using?

I was using the latest release (v0.6). I'm thinking about going and compiling the source, though, as that seems a bit more updated.

 

From what I can tell by looking at the source here they do not seem to be correct. I am not sure about that though; I don't know if the normals have been changed since being read from the object file but since they are signed numbers should they not be multiplied by 127?

 

So changing this:

if (IsOutdoors == true)
{
     VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.X * 255.0f)) & 0xFF));
     VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.Y * 255.0f)) & 0xFF));
     VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.Z * 255.0f)) & 0xFF));

... To this:

if (IsOutdoors == true)
{
     VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.X * 127.0f)) & 0xFF));
     VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.Y * 127.0f)) & 0xFF));
     VertData.Add((byte)System.Convert.ToByte(((int)(VertList[j].Normals.Z * 127.0f)) & 0xFF));

... Should result in better normal calculation? I don't really know much of normals other than how they change the lighting of a texture.

[DeathBasket]

Yes, just download the source, change those lines and compile.

 

 

I don't really know much of normals other than how they change the lighting of a texture.

 

Normals simply define the direction a plane (in 3d space) is facing. In this case they are used to update the shading; if the normal points towards the Sun's (light source) position then the triangle is highlighted, if it points away then it is darkened, etc.

[xdaniel]

It's been mentioned before, but I can't help but be again reminded of how we really need a collaborative effort for a new, more capable and better maintained map importer. SO is a mess, the first rewrite went nowhere, and the second rewrite has been in the planning stages for months without much progress at all - I'm just not cut out to be the leader (and in this case, sole developer) of a project of this scale.

[Zeth Ryder]

Would it be possible for someone to compile the change and post a link of the new one?

[Jason777]

Personally, I think the GUI is just fine and the xml based scene settings are clever. The only things which need some fixing up are automatic error checking (such as the injection offset problem I brought up awhile ago) and more customization of polygon types (we're only able to use the definitions available). Another thing that would be nice is implementation of spinout's z64-tex-ext. Of course, I haven't looked at the source code so those are just issues I have noticed at a glance.

 

Zeth, I'll post the compiled fix later when I get back on the computer.

[Zeth Ryder]

Personally, I think the GUI is just fine and the xml based scene settings are clever. The only things which need some fixing up are automatic error checking (such as the injection offset problem I brought up awhile ago) and more customization of polygon types (we're only able to use the definitions available). Another thing that would be nice is implementation of spinout's z64-tex-ext. Of course, I haven't looked at the source code so those are just issues I have noticed at a glance.

 

Zeth, I'll post the compiled fix later when I get back on the computer.

 

Thanks I appreciate it! :3

[Arcaith]

Let me worry about the GUI

[Okami Amaterasu]

If I were able to code, I'd offer to help, but since I can't code... Sorry.

[Jason777]

Sorry for my tardiness, I was out with friends and didn't get home till late last night. Besides that, I hadn't yet installed OpenTK. Anwyays... normals are a little better on my map, but it still does it more harm than good. I guess I'll have to do without it. It's a shame, normals really make textures seem so much more lively. Here you go Zeth (I'm pretty sure you know which file to download):

 

http://www.mediafire.com/?ou3ilql0dl3l3

 

EDIT: I'm actually looking through the source code right now... If I gain a better understanding over OpenTK's library and the flow of SharpOcarina's code (not to mention a basic understanding of C#), I'm pretty sure I can add/something in this program. I already know a lot about C++ and a decent, self-taught understanding of C from looking at a lot of spinout's and Marshall's source code.

[DeathBasket]

Any other problems with normals would probably be from the obj exporter (which are you using by the way?) since they are being read from the obj file. It's possible we could come up with a way of calculating them based on reading the triangles the display list draws but if the exporter is getting them right then that's really unnecessary.