Zelda64 Actor Viewer status thread

[cooliscool]

Thanks much, both of you.

The plans I have for the program are immense.. continue to watch this space.

 

[Cyberman]

Thanks much, both of you.

The plans I have for the program are immense.. continue to watch this space.

I'm glad you are having fun with programming. Most people don't have the patience

It looks like you have made some fun progress. I take it your plans have to do with messing with some ROM data?

Cyb

 

[cooliscool]

The program's been an editor for quite a long time (and its editing functions are always expanding). The maps and actor models are all "ROM data", so what exactly did you mean?

 

[Cyberman]

The program's been an editor for quite a long time (and its editing functions are always expanding). The maps and actor models are all "ROM data", so what exactly did you mean?

I ment specifically it appears that it can be used to modify ROM data (surfaces textures). That about sums it up. Vertex, and normal data I assume aren't modifyable?

Cyb

 

[cooliscool]

Vertices are editable (dragging with mouse, keyboard, the GUI widget, or manual input of the data.. points are marked when in vertex editor mode, and clickable). Along with that, the user can modify a level's collision to match the graphics, or have the program do it for them after modifying the graphics. In future releases, the program will be capable of duplicating vertices to add graphics & collision data.

As far as normals are concerned, no N64 game stores vertex or face normals (I assume that if they're used, in lighting for example, they're calculated on the fly). The only thing that has defined face normals is the collision data (triangle based), which need recalculating after the collision's vertices are modified.

Shot 1 = Normal, untouched level with one pillar's vertices selected. Rendering just the graphics.

Shot 2 = Same as above, though the collision is being rendered over the graphics, which is colored based on its function (will explain those at a later time).

Shot 3 = The end product (I went ahead and got rid of all the pillars for fun ) Graphics modified by me, let the program match up the collision.

Shot 4 = Ingame. :flowers:

Shot 5 = Heheh.

Best part is, it took less than 1 minute to do all of that. =]

Edit: ignore the "273" text box... just debugging stuff.

 

[mdtauk]

How likely is it that there will eventually be an importer/exporter for level and collision data so you can edit the level in something like 3ds max or maya, and then import it into your editor, to determine types of collision, add entrances/exits, and add objects, actors etc...

 

[cooliscool]

You can already export graphics and collision geometry. No importing yet, but I should have some pretty awesome things to show regarding that once the "NDA" is up.

 

[cooliscool]

g_setenvcolor and g_setprimcolor implemented.

arty:

(yeah, think the N logo needs some work.)

 

[blueshogun96]

Good for you

Once again, I just wanted to say I'm glad to see you're still working on this. What else needs to be done? :flowers:

 

[cooliscool]

Finished actor model collision triangle/collision properties editing (was previously only for levels)..

In the below shots, the Time Block's shape has been changed, collision matched and normals fixed, and it's been made climbable.

 

[mdtauk]

Wonderful to see you back and to see yet more progress!

 

[cooliscool]

Thanks mdtauk.

Preliminary .obj importing (vertex colors randomized program side, model's custom). :borg:

 

[Elite Knight]

Hey can u make a way to edit the models in milkshape or 3ds max 7 higher.

 

[mdtauk]

Hey, the imported location seems to be working out great, and I notice some basic collision is there or is it advanced

Here are a couple of obj files for you to try. These were a couple of locations I was working on when we were last talking on IM, can you see if these work when converted to zmap and perhaps post some screens here if they do...

Two Test OBJs RAR File

 

[Danny]

Wow your making great progress with this Cooliscool

Keep up the great work man

 

[cooliscool]

mdtauk, the only problem with your models is that there's no separation of the mesh at all. F3DEX2 has a 64 vertex per-group limitation. I know at least Cinema4D supports automated grouping (you could group by material, "g"). In the future the program will be more intelligent and will do this on its own.

 

[mdtauk]

Ok Try These now CoolIsCool

http://mdta.thetvroom.com/two-seperated-objs.zip

 

[Mariowario130]

so pretty soon we'll be able to replace the models with Twilight Princess ones?

 

[mdtauk]

Not likely, as Twilight Princess models will use many more polygons and textures which the N64 engine couldn't handle.

 

[Cyberman]

Isn't there a media issue too? I mean you would have to first RIP the UDF file system off of the Zelda disk. Next you would then need to reconstruct it and you would have to have the new image be able to play. The other option is mounting the image (hard disk?) and getting the game to boot (magically). Either way hacking any Wii or GC data would be in the grey to dark grey zone (think piracy issues).

You can distribute hacks just not original media.

Erstwhile, cooliscool for importing data into your tool, is there a script system to allow it? IE if someone had a model in XYZ format all they would need to do is write a script in say LUA (IE you would have an LUA interpreter built into your program) that worked with the API you have for constructing model that can import. Just a weird thought perhaps

Cyb