Nullspace

I worry: can the server bear the load?

The shader is ƃuoɹʍ

Just want to share this, related to the thing I'm doing https://gfycat.com/youngheartyantarcticgiantpetrel (gif too big to embed here)

On the tedious journey of making a PSMD-like toolkit. Episode 1c: Engine test, Godot.

So why I don't try a sane engine (may have to do it later)? it is mostly a single factor: Ease of distribution. The engine/editor is a single executable that just works. It is that trivial to get started. And there is no account linkage to boot you out of the platform if they so desire (and lose access to assets from their store, but you choose to use those facilities).

Of course there are major drawbacks (the big ones for me are more bugs and the much smaller community and resources available). I am neither a fan of the custom scripting language, but I shall see how that goes. After all, I am just prototyping.

Getting the model to animate and render properly* required a dumb amount of work (mostly figuring out how to do each thing) and I may find easier ways to do it some time in the future, but here's the gist:

• Export separately each animation (around 27 .dae), there are several "repeated" animations, I am unsure if this has some meaning. We only have to export the textures once.
• If you choose to modify the textures, you may skip this point. If you--as I-- wants to use shaders to wrap the original images, you need to make sure that your textures are imported as Image (then using them as ImageTexture) and not StreamableTexture (a bug of the design kind), because you might get ugly seams in the borders of your texture due different default sampling options.
• Import them into Godot (drag the animations to a folder), I was suggested to use the Animation > Storage > Files ".anim" + Keep Custom Tracks in Import Options, but I don't think it changes anything (all of the anims overwrite the same file). Also, in the same import options, for materials, I choose Storage as "Built-In", since I was going to override the materials anyways.
• Choose one .dae (it doesn't really matter wich one, maybe put it in another folder) and create an Inherited scene. Add an AnimationPlayer node to it. Copy all animations to this node, many animations require some slight tweaking at the end (lengthening the total time, removing final nodes) so as the cyclic animations look good.
  • For animations that don't use vines, disable the animation track, set to invisible the models (and set to vivisble in the ones that use it), or erase all but one keyframe and set the values to something correct (they twitch and fly away haphazardly beyond the clipping frustum)
  • I have not tested, but it looks like the copied animations reference their original source. Deleting the original .dae(s) may cause errors
  • The material (texture) animations were not saved in my case, but it is not that hard (but again, time consuming) to make another animation for those. If you use the default material you need to change the UV offset to change the eyes's expresion, and the mouth.
• In that new Inherited Scene, choose each mesh and create a material. If you modified the textures you can use the default SpatialMaterial, and point it to the correct texture (In the 'albedo' section), if you did not then Create a new ShaderMaterial or convert the default material to a shader one. You can save the material and reuse it (for example, the body texture is used in 4 meshes and the iris in two.
  • Write the dumb shaders (this took me an embarrassing amount of time for at most 4 logical lines, and at least 1; there's some sense of contravariance that makes my head die) May explain the shaders later.
  • Don't talk to me about normal maps or I die.

This is the thing for now, see ya later, I might talk bout the shaders next.

On the tedious journey of making a PSMD-like toolkit. Episode 1b: ...And textures get in the way.

This is more of a memento to myself, or reminder to those that use the same resources as I. You can have different results depending on the engine and exporter choice, here I am using Godot 3.4, please don't burn me if you lost some hours of your life. Also, I am most certainly sure that not all pokemon have the same structure.

The .dae contains a collection of meshes and material information (we are only interested in the UV data)

• For this green snek there is the body, head, left pupil, right pupil, eyesockets, left & right vines, and for some reason the left arm, leg and part of the tail combined

The models and animations usually work fine, but the textures are another story.

To the point:

• Many textures are supposed to duplicated/mirrored in the shader.
• Textures are low resolution
• Normal maps are (I think) in object space and mixed with an alpha channel which seems to have different uses. I need some more research on this.

1st: Many textures are supposed to duplicated/mirrored in the shader.

If you merrily try to import as-is your model, you might get something like this (some meshes hidden, note that I tried to compensate scaling the uv coords):

(Is snivy two-faces?)

That's because this is what the body texture should look like:

But you only get a half from the original files.

The eye texture is a more involved example. It's a bit hard to describe:

• There is a base mesh and texture for the eye socket and whites
• The pupil is another mesh and texture with an alpha map

The texture you get is like this:

[Oh noes, the next image is WRONG, please standby before i try to make it better]

What you want is like this (Or maybe each half mirrored along the green lines, ymmv)

If you got the mirroring wrong this can happen:

(Cross eyes?)

The pupils expect the same kind of texture, but you get one single pupil. In this case you may only scale the uv map 4 times in x and y and it will be fine (don't forget to enable transparency)

(Scared? I have not yet fixed the eye alpha map, I think it will require writing shaders)

You may bake-in the eyes into the eye-whites texture (and remove the pupil meshes), but you will lose the possibility of eye movements.

The mouth is also weird:

Get:

Need:

(Smiles goes for miles)

2nd: Textures are low resolution

I mean, they are not super-low resolution and it is certainly not a road-blocker. But a pass through a upscaler might appeal to you (Waifu2x works for this well) Yet, this adds another step to the "pipeline".

3rd: Normal maps are in object space and mixed with an alpha channel which seems to have different uses.

Oh boy this one is _really_ ugly, a full post may be required and I have not yet solved it. See ya later when I address this (or not, depending if I solve it).

On the tedious journey of making a PSMD-like toolkit. Episode 1a: Some Pre-prototyping and the many unexpected things along the way.

[This has been updated 06/01/2020]

A word about myself, that I lent from someone else: I'm a mediocre man, with mediocre knowledge. Also, I am more of a programmer (not game programmer tough, the only game I  have made was a tetris thing long ago) than an artist. If you find yourself knowledgeable enough to qualify my actions as asinine, please do tell me, so I might be less ignorant.

The first thing I like to do when doing a project is to check if it is viable at all.

In this episodes I will try to make sure basic stuff actually works, so I don't die mid-attempt.

The first: Assets.

That means, images, models, textures, materials, animations, sounds, music, even plain text files. Most of the stuff is trivial. Using the 3DS models is the part really I wanted to test.

The first thing I found, is that there are some models over the models resource, but they lack animations.

So, let's say you have the unencrypted image of USUM, how do you get them pokes (with animations)?

Thanks to some very talented and/or dedicated people that have made some useful tools it is not that hard (but it can be tedious). The steps are in general

• You need to extract your game image.
• You need to extract the file (inside the game image) containing the pokemon models' data (thousands of .bin files)
• You need to convert the files (pertaining to each poke) in to a digestible format for your engine
• You need to fix stuff that converted wrong

If you want more detail do search "usum/swsh models" look for the recipes.

Something of note, too, its that you can bypass the first two steps (some madlads over DA have uploaded the extracted files), but I was testing the waters to see if it was possible to automate the whole thing.

There was a tutorial that suggested to use Hacking_Toolkit3DS to extract the game image, but, eh... The latest version V12 did nothing (making me suspect it was actually a trojan) and the previous one do extracted them but not in the way the other tools liked it.

Seems that some tutorials were outdated, because they mentioned Pk3DS for the second step; but, surprise, it now can to the first one too. It takes a loong time, and some gigs (15 GB I think) of additional space to do it, but it does it well.

(D'oh)

(This file a/0/9/4, contains all the relevant data)

(Then we drag it here to get thousands of .bins)

The real pain starts when trying to convert them. The data for one pokemon is not in a single .bin file; it is separated into the mesh, textures, and animations (9 total files usually). The files are not named, only numbered, so you would need to look up what numbers correspond to what Pokemon. A guy has compiled a list of corresponding numbers.

The other thing is the tool that does the conversion. I found Ohana3D and SPICA. Seems SPICA exports better animations (but it cannot import, but I don't need that) so I went with it.

Here comes the first huge pain.

There's no (reliable) automated way to convert them all in one step. *

In SPICA you have to merge the files needed, then select the animation you want to export. You need to this for every pokemon (and each animation you want). Oh no. There is also a SPICA fork that automates the thing about several animations, but due complexities around .DAE format it just stitches them in a single animation, which for some engines it's actually more work to untangle. In the flipside, it has a CLI interface, which, theoretically--with some modifications--could be used to automate it. 

Using the GUI (as the shown image) is a bit weird but works. To save the currently shown model and animation (click the bone icon to see them), use the floppy disk icon. To save the textures use the up file with up arrow icon. There's the batch export option, but it does not support animations :c (correct me if I'm wrong).

Then it comes the second pain: the textures will, most likely, be wrong. 

I think I shall continue that in a next post

[*] I have heard there's someone trying to automate that for Unity. [Citation needed, I lost the link :c]

The green danger noodle.

On the tedious journey of making a PSMD-like toolkit. Episode 0: What I am even trying to do.

Since I have no idea where in the forums could this fit, I place it here, in a sort-of blog manner. I suppose if this continues, I shall aggregate these later where appropriate.

I might fail in the endeavor, but the way walked to failure will be registered too.

1st: Why.

Just because. Well... that and there seems to be a lack of proper Mystery Dungeon fan games. I believe there's some console mods out there, but I am not acquainted very well them; there's also a weird mix of an real-time multiplayer rpg (PMD Universe, if I recall well), but I didn't quite like it, although I might steal, compare get some ideas from it.

I am quite unsure if I will finish this, but I am already learning a lot from bashing my head against dumb problems that happen even this early. If someone wants to continue (or in the unlikely, and hard, case of collaboration) this work, you are very welcome.

Now, why not classic 2D Mystery Dungeon? Here a list

• Let's do something different. There are a lot of 2D rougue-likes-likes (ie. Mystery Dungeon series). It also allows for things that would be very hard or time consuming with 2D sprites (camera, animations, non planar dungeon topology)
• The latest sprite based game only covered up to generation 4, thus I would find myself needing to use a lot of fan made sprites.
• I hate some of the PMD sprites.
• USUM/SwSh have all the animations I think I will require up to their generation. (A mystery-- USUM has walk and run animations for every poke but doesn't uses them)

Why this could be a disaster:

• Importing stuff it's not usually trivial. I will talk about that in another instance, but suffice to say, the games' models have some idiosyncrasies and limitations, thankfully none of them fatal (I hope). The bigger issue here it's that  I cannot (yet, perhaps) only require an 3ds image and automagicly extract the data required. Thus it will be required to provide all the models and textures. That's so obviously asking for a DYMCA. I get they might let games like Reborn live (hopefully forever), but it seems they are a bit more protective of the 3d stuff (It looks like Let's Go Unity was terminated, for instance).
• 3D Art is harder to make (At least for me, that's, I have no idea how to texture a donut). Also, there are a lot more 2D artists.
• Actually taking advantage of 3D in dungeon gameplay breaks many, many common tropes of game mechanics of the genre. I think I will make some compromises. PMSD despite rendering in 3D, it's more like 2.5D, as all dungeons are planar, square lattices.

Thus I have abandoned the hope of making a full game (I would have loved to make a heart-breaking story), and decided to make "just" a toolkit, so that in the remote possibility that I in the future (or you reader) might be able to tell a story in that style.

2nd: What.

So in the end, what _should_ be the result

• A ludicrously short demo
• The project files of the game
  • (The polished textures/models/animations???) [What do]
  • Source files of the game and plugins/add-ons of the engine that were developed to aid development
• Tutorials/Blogs (like this one, hopefully it's not garabge) that describe the journey. Also: Comments and critique are more than welcome

3rd: When.

Uh...

3st: How.

That's the whole purpouse of this series. See you soon, hopefully