Thread resurrection: Remodel Zelda

[Mireneye]

Ususally when making armors or clothing for games like Morrowind, all you need to get approporiate deformation and animation is to have the body/clothing linked to a biped or a set of skeleton which contains the same bones and functions. And I think that one may find that out by sniffing in the model format. just my 2 cents.

 

[DeathFox007]

Still, the emulators are basically limited to the basic ops and stuff a N64 could do.

But then again, N64 console cant handle 32 bit picture files or display almost all the colors in the spectrum. But w/ the emulator, its possible. So who knows bout the model stuff. Maybe it could be done

 

[Toasty]

I certainly agree. But what if somehow there was a way to alter the locations the vertices would move. I have no experience with modeling or programing, but it's just a thought.

My guess is that it would be a matter of identifying which areas in code modify vertex information and inserting customized code that modifies the new vertices properly. No trivial task, though not impossible by any means. What it really would take is a ROM hacker with lots of time on their hands. If I knew more about 64 emulation I would give it a shot, but I'm still way back at the Chip8 and sound processor emulation level.

Hmmmmm, noobie brainfart - I'm not sure how the 64 video plugins work (we really need an experienced emulator/plugin programmer in this thread) but if they convert the vertex buffers that the 64 uses into vertex buffers that the graphics API natively use on a per-model level (in other words if models get sent from emulated 64 memory to video memory individually) or individual sections of models get brought over at a time, then maybe a model could be replaced in video memory only and then when vertex position changes are sent from the emulator to the graphics API, a translation matrix could be computed to apply somewhat accurate changes to the modified model.

Or if the models don't get sent individually, maybe the emulator could record what parts of the scene are specific models before the whole thing gets sent to video memory and then the graphics API could do the same thing I mentioned above.

I'm not sure if I understand all the stuff I just said or if anyone else will, but it seems like that might work, without the need for game-specific customizations in the plugin. I probably don't have any idea what I'm talking about though. The complexity of a 64 emulator and its plugins is far beyond me right now. We need Rice or Orkin to pay a visit to this thread me thinks.

 

[Mireneye]

I think that could work very well. Ive seen the plugin which can extract models from games, so, they have apparently already cracked the model format somewhat. Extending upon that, what is needed doing is letting the same outputted model to be loaded "Ovveride" The old model. Then it would only need same procedure as texturing.

Good brainstormin!

 

[Toasty]

Now we just someone to implement this idea in their plugin.

 

[Mireneye]

Im attending a Swedish Secondary school for Programming. But I could never do anything that complex... I talked to one of my friends at school who's a real C++ and general Programming Genious / Nut... He said that it should be very possible, so apparently, there should be a good chance.

 

[Im Bored]

i just wanna throw some shit in: how long exactly would remodelling zelda take? Christ! the mind boggles. Takes long enuff to "just" retexture a game, and even if you only did the character models, wouldnt they seem out of place? Im happy enuff just editing existing models in games and not adding more vertices. I dont see a need.

 

[Toasty]

Another idea occured to me today in the shower (isn't that where all good ideas originate?) that instead of having to have the graphics plugin come up with a translation matrix, the custom model could just have the translation information packaged with it by whoever made the model. That way when the game tells the plugin to move a vertex, the plugin can just look up which of the modified model's vertices should be moved and how much/where they should be moved. A little more work for the modeler, but it would probably produce more accurate and less computationally intensive vertex movement calculations.

 

[Amon_Knives]

Another idea occured to me today in the shower (isn't that where all good ideas originate?) that instead of having to have the graphics plugin come up with a translation matrix, the custom model could just have the translation information packaged with it by whoever made the model. That way when the game tells the plugin to move a vertex, the plugin can just look up which of the modified model's vertices should be moved and how much/where they should be moved. A little more work for the modeler, but it would probably produce more accurate and less computationally intensive vertex movement calculations.

And to think this all started when I just thought of something. I only know half of what you said, but I think I could probably study your posts and pass my computer tech class. lol.

 

[Mireneye]

Another idea occured to me today in the shower (isn't that where all good ideas originate?) that instead of having to have the graphics plugin come up with a translation matrix, the custom model could just have the translation information packaged with it by whoever made the model. That way when the game tells the plugin to move a vertex, the plugin can just look up which of the modified model's vertices should be moved and how much/where they should be moved. A little more work for the modeler, but it would probably produce more accurate and less computationally intensive vertex movement calculations.

Im rather sceptic that it would be as good. I see that it may be very difficult to add more polys/tris to the engine that way. And you probably would need to come up with a new Model file and create a exporter for it"Well, you probably need similar for the other idea aswell" But I think easiest approach is to exchange the models in the memory. Ofcourse, textures would also need to be reassigned and then the mapping would also need to be figured out, but thats ususally included in the model file, but not always.

 

[Mireneye]

Another idea occured to me today in the shower (isn't that where all good ideas originate?) that instead of having to have the graphics plugin come up with a translation matrix, the custom model could just have the translation information packaged with it by whoever made the model. That way when the game tells the plugin to move a vertex, the plugin can just look up which of the modified model's vertices should be moved and how much/where they should be moved. A little more work for the modeler, but it would probably produce more accurate and less computationally intensive vertex movement calculations.

Im rather sceptic that it would be as good. I see that it may be very difficult to add more polys/tris to the engine that way. And you probably would need to come up with a new Model file and create a exporter for it"Well, you probably need similar for the other idea aswell" But I think easiest approach is to exchange the models in the memory. Ofcourse, textures would also need to be reassigned and then the mapping would also need to be figured out, but thats ususally included in the model file, but not always.

 

[Toasty]

The additional translation information wouldn't have to necessitate a new file format, it could still be stored separately. For example, suppose the API the plugin uses is DirectX and it allows models to be imported in the .X format. When the plugin loads the model, it could also check for a file with translation data. If the file was present it would use that data to help translate vertex movements; if there was no translation file, the plugin could either default to creating a translation matrix itself (probably not as accurate), or just not use the custom model. Ideally, in the model folder you'd have two files for each model, something like this (I'm not sure how file names would be assigned to identify models, but I'm guessing it would probably be something like redone texture file names):

GameName_Model#1234ABCD.x (contains the enhanced base model that will be imported)
GameName_Model#1234ABCD.trans (contains customized information that describes how the new vertices should be modified when one of the original ones is changed)

 

[Mireneye]

Now that is good reasoning. I hope somebody is taking notice of this, somebody really experianced!

 

[Mireneye]

Usually, I work like 9+ houers before posting something. However, I think I need alot of work on it to make it look more 'Linkish' Right now, its like a mature Mido Version me thinks... AAAH! Any crits welcomed, and, id really like to know, if I should post this in a new thread for next update ?

Cheers
Note: Im currently ashamed of this model, I can do alot better so please, do give me good and constructive criticism to follow!

 

[neo64]

Hmm... who is it? Link??
Sorry. The whole face doesn't look like Link at all... Mido is who came in my mind first. I think you should rework the face and the hairs...
but it is not bad, it only doesn't look like Link.

 

[Mireneye]

Ooh, yes its bad... Put one or more houer into it and you may have it halfdecent!. Well, more in this way atleast...

However It still lacks Link.. Maybe, ill redo the whole head... someday later.

 

[Amon_Knives]

Put freckles, red hair, and a shorter hat and it's mido.

 

[neo64]

Redoing the head is probably a good idea Try to make the whole thing more manga/anime-like.

 

[porjay]

Redoing the head is probably a good idea Try to make the whole thing more manga/anime-like.

No because this is Ocorina of Time NOT Wind Waker :ermm:

 

[Mireneye]

Im, IMO much better at realistic likeness then Anime style. But I know what you mean. I really need to go through some planning on next try.