MV3D - 3D rendering for RMMV with Babylon.js

@Waterguy a patch for Qsprites itself would be a huge world of diference !!...would be awesome!

I have a question. Does this support Android?

@palatkorn someone I know already tested, and yes.

@k333 and @Dread_Nyanak and whoever else cares...
I DID IT!
I did a compatibility patch for QSprite and this plugin!
Let me tell you, it wasn't exactly easy... for one simple reason. Well, two actually.
1- QSprite is locked inside an IIFE. That means unless I edit the plugin itself, any changes need to be copied outside. That was locking some functions away from MV3D, like... the whole point of using it, really.
2- MV3D may not technically be an IIFE, but the way classes work in javascript compared to prototyped functions which most people use it may as well have been. Had to jerryrig a way to access the character_Characters when they are made instead of just adding to it like most plugins allow.
(I admit it may be lack of knowledge on my part that made it harder, but it did make it harder)

But regardless of the troubles, I did it!

Now, last I checked QSprite has to be above mv3d-babylon to work, and this bellow them, but it is plug and play besides that.

(on an unrelated note, the QSprite editor for some reason doesn't want to open the images anymore... as it is, it shows everything, saves everything, but the Sample Image is always empty. I had to use the data and images of an old project of mine to test.
Anyone has any idea how to fix this, I'd appreciate it)

My gawd.. now I feel inspired to make something RMMV again.
We just need a 3D battle system now lol

Fantastic plugin!

I do have a question and forgive me if it has already been addressed.
I've noticed that events in my test playthroughs that have sprites that are larger than normal (ex. $BigMonster1, but with a sheet of a 4-directional set) are always facing the same direction when I rotate the camera around and they don't turn with the camera like a standard sized character sprite. It makes custom routes for these event sprites confusing and takes away the immersion when using an "event chase player" system for battle encounters. If I were to rotate the camera 180 degrees, the event would seem to be moonwalking away from me xD. Is there a work around to fix this?

@Fyoha what are the settings you put for the event? Did you put direction fix? What about the settings through the notetags? Could be either of those too...
Hey @Dread_Nyanak I just noticed something...
At no point of the help, in the file or in the patreon's read me, is explained what the shapes are.
We have just a list of names for what are valid where, if for tilesets or events, but no way to know the difference besides testing.

Also, is there a way to set a region to work a way just for that map through map notetags?

Impressive! Thanks for devoting so much time and effort! The outcome is just great :smile:

Directional fix is off and the notetags are empty. I made 3 different events next to each other with all the same settings and custom routes and I was only having problems with the event that had a larger sprite. I was thinking it was a configuration within the plugin for images that have the"!$" prefix tags on their file names. It keeps those images facing the same direction to the camera no matter which way you rotate it. I mean, a custom route will make them look in different directions according to the sheet, but that direction is always static to the camera.

I assume what I said because I believe a lot of bigger images use that prefix as static objects in which they do not have a fully drawn-out, 4-directional sheet and rotating a said image would alter it to something else in that sense perhaps.

*EDIT*

I fixed my problem. I had a lack of understanding of the prefix symbols and my source file image I was using had the wrong one. Changing the "!$" to simply "$" seemed to have fixed my issue. I figured it out by testing other source files with different prefixes on the file names. Rookie mistake I suppose.

@k333 and @Dread_Nyanak

I messed with the plugin compatibility patch a bit... to make it better (in my opinion at least)

Added support to 8 directions, that I forgot to add in the other one.

I had to create a function to turn numberpad directions into angles and one to turn back, but at least in my tests it worked fine.

Is there a way to make the character walk diagonally to? this plugin is probably the most perfect.

@palatkorn nlt by default in the plugin... but I have to admit, now that I made qsprites work with all 8 directions, I've been thinking on making an addition for this too...

I wonder if the direction setting when the scene began to rotate may not work correctly or it works correctly. Where should I define the opposite? This may be complicated. Too far to make it run in the right direction



[embedded media]

@palatkorn I at first thought you were talking about how the camera was jumping in place, but then I noticed so was the music so I guess it is just the recording taking a bit of your computer...

So, I don't get the problem here...
Is it that the actor always goes to the upper left of the map regardless of the camera direction?
If so... that is good, in my opinion. I can't imagine myself planning cutscenes properly if I have to worry constantly if the player's camera is set to this direction or that one. Upper left of the character is upper left of the map in the editor.

Another mistake of turning the camera is when I warp to the map <mv3d>
disable ()
</mv3d>
My movement was switched, for example, I would press up and it moved to the right.
I think you may have overlooked this, but I believe it would be something that many old projects of many people have created events and May be able to fall into the water or hit the wall and the game freezes instead
And yes it is scary

@palatkorn the movement being switched when you change the camera is... normal?

I mean, seeing your video it seemed to me that move routes move exactly as it would in a default camera map regardless of angle, so I'm assuming you are talking about the player's control.

If you for example move the camera 180 degrees so it is looking from the top of the map instead of the bottom like usual, it is expected for controls to change so pressing up goes down the map instead of up.
I just tested, and when I changed maps to one with mv3d disabled the controls went perfectly to up being up.

With this and the previous post, I think you are mistaking something.
This is a visual plugin. The only change in controls is so when camera is turned the keys respond properly.

Events, like move routes, work just the same as in the default maps - because it is what it is, the default map with 3d view, but still the default map.

Pressing up when the camera is turned does not make everything move to the left instead of up, the controls are just changed so pressing up does what pressing left would usually do.
The controls are changed. The actual movement is not.

It happened when you adjusted the camera I tested in the initial project.
The operation of the control buttons is distorted.
In addition, the camera operation remains when pressing Q / E on the disable map.

Well... you did show me happening to you. As I saw the key presses, I can't think what else could be the cause there.

I then did the same thing you did. Opened the example project, added an event with a teleport to the disabled map, and turned the camera before teleporting... and it did not happen to me.
The pat-reon-exclusive plugin was not even on, so it can't be it.

So... is your version the latest one, from three days ago according to github? Mine is.
If you download the newest version and it still is happening to you but not to me... I have no idea what else it could be. Maybe an incompatibility with another plugin, but that's all of my ideas here.

OK, I will try the latest version and if I find a new error I will report.

I tested it in the latest version, it doesn't seem to happen.

@Dread_Nyanak my time to point a problem, I guess...
This is apparently a problem related to the patron plugin though.

Sorry I haven't posted here in a few days. My internet has been really bad lately, and there's also the holidays.
Anyway, right now I'm working on rewriting a lot of the movement and collision code. I'm making the z axis into a real dimension. When I'm done you will be able to make a bridge that you can both walk over and under. You will also have to be at the same height as an event to trigger it.
I'm also adding vertical rotation for events like @k333 suggested.

@palatkorn
I was about to tell you I fixed a bug like that in a recent update, but it looks like you figured that out while I was trying to post this.

@Fyoha
There's also <mv3d:dirfix(true/false)>. Set it to true to prevent the event from rotating with the camera. As you've found, object sheets (starting with !) are dirfixed by default.

Yes, this is exactly the kind of style that this plugin works really well for.


I thought I had a part explaining what each of them did. I must have removed it when I reworked most of the help text. I'll have to put a proper explanation back in.


Not at the moment, but it would be a good feature idea.

For the transparency issue with the patreon plugin, yes it's a problem with alpha fog. Babylon unfortunately ignores alpha blended objects when building the depth map and shadow map.

It'd be nice if I could find a way to tell Babylon to treat these objects as solid when rendering shadows and the depth map but transparent when actually rendering them, but I haven't found a way to do that.

It's a problem I'm aware of and want to fix. Unfortunately it's not easy to fix.