SharpOcarina - Zelda OoT Scene Development System

[Okami Amaterasu]

I found a bug in the newest version I thought I'd report. If you add an exit, double click to change the value, then delete the exit while it's still in the "edit mode" it'll cause an exception.

 

I also have a suggestion. Would it be possible to make the collision function use the collision model instead of the room model(s)? That way you could have walls and things while having higher poly things behind them that have no collision.

[Kargaroc]

How do you make, for instance, a door, in Sharp Ocarina? I don't really know how to.

 

Second, in the next version of Sharp Ocarina, could you increase the maximum scale of a map? My maps are very small (at least that's what it says), and I can't make it big enough. If I could make the scale 40 or 50 then I would be happy because that's what I did with the old importer

[Zeth Ryder]

What are the values for each of the ground types? I couldn't find anything on wiki on it.

[xdaniel]

Okami: Will look into the bug; collision-less things are made by removing them from the collision model, but having them in the room model. That's how water surfaces are done. Or am I misunderstanding?

 

Kargaroc: Doors are transition actors; best have a look at the demo dungeon and see how its doors work. As for the map scale, especially if you're doing indoor maps you should best scale them in your modelling program, otherwise it might be really difficult to fit doors or other such actors in correctly.

 

Zeth: http://wiki.spinout182.com/w/Zelda_64:_Collision_Format#Polygon_Types <- "Sound effect/ground type"

 

Also, I'll see about making a new build later that'll at least contain the changes currently on the SVN.

[haddockd]

Quick Q xDaniel,

I haven't been successful in my importing yet, but can I assume that climbable collision == hookshotable collision? If not, is there expected support for that in the future?

I know in UoT you could make something either climbable or hookshotable (or at least I thought so).

[xdaniel]

haddockd: I knew I missed something. I'll add a simple checkbox for that in the next build; in the meantime, you can change the setting via the collision type's raw data: 0000000000020000, the bolded 2 meaning hookshotable.

[haddockd]

Cool, Thanks. I have been building the source for myself at each change. So I always have the latest build. Not sure that's always a good thing though

[DeathBasket]

@some stuff I saw in the shoutbox: afaik there shouldn't be an issue with darkened RGBA5551 textures, but looking at xdaniel's code:

		private ushort ToRGBA5551(byte R, byte G, byte B, byte A)
		{
			return (ushort)((((R >> 1) & 0xF8) << 8) | (((G >> 1) & 0xF8) << 3) | (((B >> 1) & 0xF8) >> 2) | (A >> 7));
		}

I don't think that's the correct way to convert the colours... I haven't noticed the problem myself (or I might just not have used any textures that get converted to that format yet) but I'll try playing round with the source a little.

 

Edit: a quick fix is just to remove the "x >> 1", but it's still not totally accurate.

Edited September 9, 2011 by DeathBasket

[john_smith_account]

@some stuff I saw in the shoutbox: afaik there shouldn't be an issue with darkened RGBA5551 textures, but looking at xdaniel's code:

		private ushort ToRGBA5551(byte R, byte G, byte B, byte A)
		{
			return (ushort)((((R >> 1) & 0xF8) << 8) | (((G >> 1) & 0xF8) << 3) | (((B >> 1) & 0xF8) >> 2) | (A >> 7));
		}

I don't think that's the correct way to convert the colours... I haven't noticed the problem myself (or I might just not have used any textures that get converted to that format yet) but I'll try playing round with the source a little.

 

Edit: a quick fix is just to remove the "x >> 1", but it's still not totally accurate.

 

I may come out sounding very stupid on this, since I can't read the source code, but...

I vaguely remember having a similar problem in converting textures to 8-bit.

 

In my case I shifted the bits to higher values to solve the issue.

 

Lets say the 5 bit value was

10111

one would assume to convert it to 8 bits it would be

10111000

In whatever I was coding, that didn't work, so I shifted the bits over (multiplied) the value.

10111

becomes

00010111

Again, I can't read your source code so hope I don't sound dumb.

[DeathBasket]

I've rewritten it as this:

		private ushort ToRGBA5551(byte R, byte G, byte B, byte A)
		{
			float X, Y, Z;
			int U, V, W;
			X = ((float)R / 255) * 31;
			Y = ((float)G / 255) * 31;
			Z = ((float)B / 255) * 31;
			U = (int)Math.Round(X);
			V = (int)Math.Round(Y);
			W = (int)Math.Round(Z);
			return (ushort)((U<<11)|(V<<6)|(W<<1)|(A>>7));
		}

Which seems to give the correct results, at least on the textures I've used.

Simply doing bit shifts isn't always correct in this situation because it will not get the ratio correct.

ex. in your situation (5-bit to 8-bit) 11111 should become 11111111, but a bit shift would give you 11111000 instead.

[john_smith_account]

I've rewritten it as this:

		private ushort ToRGBA5551(byte R, byte G, byte B, byte A)
		{
			float X, Y, Z;
			int U, V, W;
			X = ((float)R / 255) * 31;
			Y = ((float)G / 255) * 31;
			Z = ((float)B / 255) * 31;
			U = (int)Math.Round(X);
			V = (int)Math.Round(Y);
			W = (int)Math.Round(Z);
			return (ushort)((U<<11)|(V<<6)|(W<<1)|(A>>7));
		}

Which seems to give the correct results, at least on the textures I've used.

Simply doing bit shifts isn't always correct in this situation because it will not get the ratio correct.

ex. in your situation (5-bit to 8-bit) 11111 should become 11111111, but a bit shift would give you 11111000 instead.

 

11111 would become 00011111

Least Significant Bit starts on the left(edit)?

I understand what you mean about using ratio, however if I'm not mistaken the higher bits are higher values, and each of the lower bits are are lower values. Therefore you ignore the lower values, as they only create different shades between the higher values.

 

I'm pretty sure that is proper conversion.

 

A direct multiplication of the bits also preserves the original values, and removes any chance of rounding errors upon multiple conversions

Humor me please, multiply the values by 8 (R*8) (B*8) (G*8) for conversion and check the results.

Please.

 

Edit: I said right before, I meant left.

[SanguinettiMods]

It hasn't darkened any textures until I tried using it for converting a Display List. Not only did the colors darken, but One texture had some Red and the other tetxure had some teal. The Red on the texture became teal and the teal on the other one became red.

 

...Not that is was meant to convert Display Lists... I just can convert it.

[DeathBasket]

I understand what you mean about using ratio, however if I'm not mistaken the higher bits are higher values, and each of the lower bits are are lower values. Therefore you can ignore the lower values, as they only create different shades between the higher values.

A direct multiplication of the bits would preserve the original values, and removes any chance of rounding errors upon multiple conversions

 

True, but if something had a value of 7 then a bit shift would make it zero when it should actually be closer to one (0.8...). That probably shouldn't bother me as much as it does... You'd also not be able to get a pure white if converting back this way since you'd get 248,248,248.

Rounding errors don't matter too much here since the conversion is only one-way. I don't see why somebody'd want to create a texture, convert to this format, convert back and then convert again.

Regardless, removing the right shift in the code as I said earlier will output textures that look fine and is simpler than my way of doing it so is probably the one that should be implemented.

 

 

I'm pretty sure that is proper conversion.

 

It is, I just have a background in maths and not programming so... that's just the way I do things I suppose.

 

Humor me please, multiply the values by 8 (R*8) (B*8) (G*8) for conversion and check the results.

Please.

Can't really be bothered right now. I probably wouldn't be able to tell the difference between that and the way I'd do it but... maths OCD I guess.

 

SanguinettiMods: you probably don't notice the darkened textures on a map because of the lighting. I can show you some screenshots for a comparison if you like.

[SanguinettiMods]

SanguinettiMods: you probably don't notice the darkened textures on a map because of the lighting. I can show you some screenshots for a comparison if you like.

 

Sure.

[john_smith_account]

Sorry to get uptight... and yes math IS OCD.

 

Anyways I see what you're trying to do with your method VS what I'm trying to do with mine. You're trying to preserve the extra data, the extra 7 shades produced by 8-bits versus 5.

 

But you can't. You can kinda but not really.

 

All using a ratio conversion can do is bump the color up a single shade. Since there are no half values here, we are only dealing with 7 shades of difference, 3 bits.

 

So your method would keep the first 3(or 4?) shades the same, and bump the next 4(or 3?) shades up. So shades 1-3(or 1-4?) are lost, not dumped up. Shades 4-7(or 3-7?) are bumped up to 8.

 

When you think about it that way, we're disagreeing over a single bit.

 

*THINKS*

 

Oh, now I get it! Actually, never mind. I think I prefer your method after all.

[DeathBasket]

When you think about it that way, we're disagreeing over a single bit.

 

I know, crazy isn't it?

I'm just used to writing things more accurately and I end up trying to apply that in programming too, but with integers this small it's pretty insignificant how you do it I suppose.

Anyway, at least we know why some textures were getting darkened now and how to fix that.

[haddockd]

xDan:

Arcaith mentioned (at least I think it was him...maybe DB) that the no object from SketchUp deal was fixed. I get the same black screen no matter what I bring in. I also dumped a scene from MM with Ozmav and the same thing...no collision, no textures, nothing. Is SharpOcarina capable of handling dumped MM scenes?

[SanguinettiMods]

OZMAV2 doesn't scale maps to the correct size, and the textures aren't mapped correctly when dumped.

[haddockd]

So do we have a better way to extract MM maps and get them into #Ocarina? I am waiting on getting 3DS Max, but until then I would LOVE to get some practice with #Ocarina.

Update:

I cannot get Blender models to load either. What options are you using (those of you using blender) upon exporting to obj? I have tried many different combos and cannot find the right ones. #Ocarina throws index out of bounds.

I know I am tiresome but for some reason I cannot get this to work for me...which is sad because I create debug tools all the time.

[spinout]

re: bits Ninty does it this way:

#define GPACK_RGBA5551(r, g, b, a) ((((r)<<8) & 0xf800) | (((g)<<3) & 0x7c0) | (((>>2) & 0x3e) | (((a) >>7 ) & 0x1))

 

Edit: God damn this stupid auto edit-your-post-because-it's-cool-to-insert-®-and-enable-emoticons.

 

Edit 2:

OZMAV2 doesn't scale maps to the correct size, and the textures aren't mapped correctly when dumped.

 

I don't remember what OZMAV2 scaled things to, but I remember it was something obscure which I worked around when I used badrdp in z64anim.

 

A lot of textures export weirdly/have "bad" mapping because they are mirrored and badrdp tries to accommodate for this by mirroring the texture manually and manipulating the UV coordinates - I, again, worked around this (custom mtl commands) when exporting for z64anim. (On the subject of z64anim, has anybody actually found it useful? lol)

 

 

On another note, good seeing you here JSA

[SanguinettiMods]

So do we have a better way to extract MM maps and get them into #Ocarina? I am waiting on getting 3DS Max, but until then I would LOVE to get some practice with #Ocarina.

Update:

I cannot get Blender models to load either. What options are you using (those of you using blender) upon exporting to obj? I have tried many different combos and cannot find the right ones. #Ocarina throws index out of bounds.

I know I am tiresome but for some reason I cannot get this to work for me...which is sad because I create debug tools all the time.

 

If you want to get MM Map in Ocarina of time, just use spinout's porter.

[haddockd]

I was hoping to leverage the features in #Ocarina that are (as far as I know) not present in spionout's importer such as adding actors/exits, a UoT like interface, etc.

[xdaniel]

Dumps done with libbadRDP - and in turn OZMAV2 - don't used .obj groups at all, so they won't work in SharpOcarina. To at least get them to load and convert, add a line "g some-name-does-not-matter" (or whatever) to the .obj model, right after "mtllib material.mtl", however you won't be able to set translucency, etc., etc. correctly as there's only one group.

[Sage of Mirrors]

Hold on.

This program is designed to make importing new maps easy.

It can also add actors, transitions, collision and environment stuff.

And you can create multi-room structures.

This seems too good to be true.

(Does it work with Blender-created models?)

[Arcaith]

It should work with Blender created models since Blender exports obj in a standard format.