SharpOcarina - Zelda OoT Scene Development System

[Okami Amaterasu]

I'm getting some kind of odd texture glitch and I'm not sure why.

 

 

 

http://s1235.photobucket.com/albums/ff433/OkamiN64/?action=view&current=2011-11-09_00006.jpg#!oZZ4QQcurrentZZhttp%3A%2F%2Fs1235.photobucket.com%2Falbums%2Fff433%2FOkamiN64%2F%3Faction%3Dview%26current%3D2011-11-09_00001.jpg

Sharp Ocarina

http://s1235.photobucket.com/albums/ff433/OkamiN64/?action=view&current=2011-11-09_00006.jpg#!oZZ2QQcurrentZZhttp%3A%2F%2Fs1235.photobucket.com%2Falbums%2Fff433%2FOkamiN64%2F%3Faction%3Dview%26current%3D2011-11-09_00005.jpg

In-game

http://s1235.photobucket.com/albums/ff433/OkamiN64/?action=view&current=2011-11-09_00006.jpg#!oZZ3QQcurrentZZhttp%3A%2F%2Fs1235.photobucket.com%2Falbums%2Fff433%2FOkamiN64%2F%3Faction%3Dview%26current%3D2011-11-09_00002.jpg

Sharp Ocarina

http://s1235.photobucket.com/albums/ff433/OkamiN64/?action=view&current=2011-11-09_00006.jpg#!oZZ1QQcurrentZZhttp%3A%2F%2Fs1235.photobucket.com%2Falbums%2Fff433%2FOkamiN64%2F%3Faction%3Dview%26current%3D2011-11-09_00006.jpg

In-game

 

 

[Arcaith]

Looks like a UV mapping error. Upload your .obj and I'll take a look at it in Max. You might have some bad texture co-ordinates.

 

Also, xdaniel, you might want to take a look at supporting plain text .x files; they support vertex colour/alpha amongst other things. They're far more versatile than .obj files. Adding support for them alongside .obj would be really useful.

[Okami Amaterasu]

This should work, but if it doesn't just tell me.

 

http://www.filedropper.com/maps_12

[Arcaith]

What did you use to export it? Looks like that might be where your problem is.

[Okami Amaterasu]

Google Sketchup Pro's default exporter. I would try exporting with Maya, but it doesn't like reading the textures.

[Arcaith]

Try using a script exporter instead. SketchUp's exporters do a bad job with grouping the model data.

[Okami Amaterasu]

What is a "script exporter?" I did figure out how to make textures show up in Maya, just just don't know how to add textures with it.

[Arcaith]

You can run ruby scripts in SketchUp. There's one that exports to obj, and properly orders the vertex, face and UV definitions. With Maya, I believe it has a material browser.

[Okami Amaterasu]

I tried with a Ruby Script exporter, and it had the same two errors (along with a few others) so I think the problem may be in the textures and not the exporter.

[Zeth Ryder]

Just throwing this here, if you plan to do any exporting from sketchup, I highly suggest you don't triangulate at all, then have another program do it, the way Sketchup does it causes the normals to get messed up.

[Okami Amaterasu]

I triangulate everything myself, does that still mess up the normals?

[Zeth Ryder]

I'm not sure, I have never tried triangulating myself.

[Arcaith]

Normals are defined by the order of the vertices in a face, I think a counter clockwise winding from the direction you face the face will point the normal toward you.

[Okami Amaterasu]

How do you tell which way a face is facing?

[Secant]

With SketchUp this is relatively easy. In this program, every polygon has two sides, front and back. The front side when given the default textures is white, while the back side is colored a pale indigo.

[Jason777]

I found something wrong with SharpOcarina release v0.5: The scene file points to the wrong offests for the maps, and the scene file writes over some of the map file space in the process. To be more specific, I believe that the automatic injection offsets calculator is the problem. This is was why SharpOcarina would cause my imports to crash/fail to load... thankfully, I know how to fix it.

 

I'll provide an example (maybe a video) a little later.

[xdaniel]

I found something wrong with SharpOcarina release v0.5: The scene file points to the wrong offests for the maps, and the scene file writes over some of the map file space in the process. To be more specific, I believe that the automatic injection offsets calculator is the problem. This is was why SharpOcarina would cause my imports to crash/fail to load... thankfully, I know how to fix it.

 

I'll provide an example (maybe a video) a little later.

 

An example of this would be nice, as no one else (unless they didn't contact me with it) has encountered this, as far as I'm aware.

 

---

And on another subject... I'm not really happy with how SharpOcarina has turned out. It's relatively simple to use and all that, but...

- its internal design leaves a lot to be desired (the kludge of how group names in collision and room models have to match up, for one)

- Wavefront .obj support is incomplete and incorrect (usage of ambient/diffuse/specular texture maps, transparency isn't supported and is hacked in otherwise, surely more)

- parts of its code were supposed to be temporary solutions but became permanent (the ROM injection code comes to mind)

 

So alongside maintaining SO as it stands right now, I have started - take a wild guess - to rewrite it from scratch. For example, each kind of "object" - that is the scene, rooms, the collision, Wavefront models and their material libraries, etc. - will be its own pair of handler class and properties dialog, as opposed to ex. every user-configurable setting being squeezed onto a few tab pages. The 3D preview will be a separate window (also a pair of handler and form), which will be capable of rendering different things, depending on which rendering function it has been given. So ex. a model handler can tell it to simply render the model, while a room handler could potentially generate a temporary room file, the Display Lists of which could be interpreted using SayakaGL's interpreter, which thus would give a much closer representation of how it's gonna look in-game compared to just rendering the Wavefront model itself. There's also a custom exception handling system in place already - it's still rather primitive, but could be extended to generate more detailed logs the user could post in case a serious problem happened, etc.

 

Yeah, much talk already, of which very little has been implemented yet. Then again, it's only a day old or something. Then again, I'm known for being lazy, loosing interest in things rather quickly, so who knows... maybe this'll be dead by Monday already.

 

 

(And even if this dies as quickly as it came, I guess at least the exception handling will probably see use in my other projects...)

 

(And I wonder if anyone will get where the "Incubator" namespace came from. Probably not.)

[Zeth Ryder]

One thing I would like to see is selecting a group and being able to do texture combining. I'd also like to suggest possibly at the end of a map file, allow for a user to add a texture for the map's name(like the location tags that load up ingame when you enter a new area), so in the scene table when the new scene offsets are added, the location text's offsets could be updated to the ones at the end of the map.

[xdaniel]

One thing I would like to see is selecting a group and being able to do texture combining. I'd also like to suggest possibly at the end of a map file, allow for a user to add a texture for the map's name(like the location tags that load up ingame when you enter a new area), so in the scene table when the new scene offsets are added, the location text's offsets could be updated to the ones at the end of the map.

 

Multi-texturing and manual changing of combiner setups is something I really want to do, so it's planned for inclusion. Depending how the rewrite goes (= if badly), I might even bite the bullet and try to rewrite the current SO to support this. As for area name textures, can they even be loaded from scene/room files? I forgot, but if that's the case, I can surely allow the user to add them at the end of the scene or so.

 

For now, here's one more screenshot of the "Incubator rewrite", now finally displaying something more than just the GUI - that is, rudimentary collision model rendering (that of Arcaith's demo dungeon models to be exact). Kinda gives me hope that something's gonna come from this, tho not necessarily much...

 

[DeathBasket]

Good luck with the rewrite and be sure to take your time with it. If you can produce a tool with all the new features and improvements it will prove incredibly useful to everyone here still modding Zelda (not that it wasn't already).

Also, I was just wondering if the source code to the older version will remain available if significant progress is made on this?

[xdaniel]

Also, I was just wondering if the source code to the older version will remain available if significant progress is made on this?

 

Most likely it will, if not directly on the SVN. I'll probably pack the latest version in an archive and put that up as a separate, deprecated download at the same time the rewrite's source goes up.

[Zeth Ryder]

As for area name textures, can they even be loaded from scene/room files? I forgot, but if that's the case, I can surely allow the user to add them at the end of the scene or so.

 

I believe so, all you need to do is point the game to the beginning and ending offset of the area location texture in the scene table right after the Map's offsets. Area textures are 144 x 24 in size, not sure the format that is, but it definitely requires that size to load up correctly. I did a test with a texture not of the same size, and it garbled a little bit cause the location text was not the size it requires, but I could tell it was my area texture, so it was reading it from the map.

[Arcaith]

If you can, add support for .x files alongside .obj files. Plain text .x files have a far wider range of supported parameters (vertex color/alpha being prime examples).

[The Tjalian]

Good luck with the rewrite xdan!

[xdaniel]

If you can, add support for .x files alongside .obj files. Plain text .x files have a far wider range of supported parameters (vertex color/alpha being prime examples).

 

I'll see what I can do. Found some documents on the specifications, which'll hopefully get me started at least:

 

http://paulbourke.ne...m_Template_form

http://www.xbdev.net...xfileformat.php

 

...that is the format you mean, right? ".x" isn't exactly a descriptive name Also, that's still some time away as I need to get the whole framework going properly and such, but gives me a reason to use interfaces again (as with the two renderers in my PCE emulator).