3D-model Stage Interface Discussions #1328
Replies: 5 comments 3 replies
-
With this we can make true 3D stages and give a Marvel vs Capcom 2 feel, I really like that game's unique graphical style, 2d characters in smooth, animated fully 3d stages. |
Beta Was this translation helpful? Give feedback.
-
Eiton's been working on implementing this for the past couple days, and I was asked to catalog some known issues here in this discussion for organization's sake, so:
(Thank you to Orange Dolphin on Discord for finding these issues!) |
Beta Was this translation helpful? Give feedback.
-
^ That can be solved using GameTime instead of Time when coding the AttachedChar. But yeah, they should reset. My two cents as a stage dev: stage elements need to be able to be addressed separately, to be managed by the engine code, via BGCtrls and IDs. If I understand correctly, the whole 3D element is a single thing, right now... And that's a big problem. A 3D barrel in front of the players should be adressable separately from the huge 3D mountain in the background. This is because BGCtrls are the key to truly complex stage behaviour that allows for more advanced things: I'd build the format so that "3DBGCtrls" are possible in the future. I know it is still too early for this, but I'd take extra care to make things expandable up to at least the preexisting BGCtrls for sprites. |
Beta Was this translation helpful? Give feedback.
-
This is a completely fair point and something I didn't really account for initially as I don't really mess with AttachedChars and the like (plus I wanted the implementation to be as simple as possible for newcomers, as well as to make it easier on the programming side of things). So since we've pretty much settled on the glTF standard, we can actually design with the capabilities of that format in mind; namely, glTF files are capable of storing the details of individual mesh objects according to their spec sheet: Note the So with that in mind, perhaps we can amend how [Model]
; new parameter: "name"
; This parameter takes the name of a given mesh object as defined in the glTF file.
; When specified, only that particular object is rendered within that block, similar to BG elements for 2D stages.
; If this parameter is left blank or undefined, then default to loading the entire scene like how we currently do.
name = "House"
; Parameters currently available in Eiton's fork
; Offset is still understood here to mean the origin of the world {0, 0, 0}.
; Since objects can have their own pivot point, the pivot should be taken into account when implementing this.
; (In other words: the object's pivot should be at 0, 0, 0 if this offset value is also set to 0, 0, 0.)
offset = 0, 0, 0
scale = 1, 1, 1
; Not implemented (at least not yet), but included for the sake of completeness
rotation = 0, 0, 0
; From skimming the docs, this parameter is apparently essential for interactive stages to work.
; It's a user-set numeric ID that can be used to point to a specific BG element.
sctrlid = 1 I'm admittedly not very familiar with exactly how interactive stages work just yet, but from skimming the docs this should allow you to at least reference specific parts of a 3D stage under this format. |
Beta Was this translation helpful? Give feedback.
-
This is an excellent idea! :D As much as I appreciate the SCTRLID (which is used for AttachedChars), an ID reference is also required (which is a normal, MUGEN stage feature implementation). Those allow to change things based on a timer alone, not player interaction. This section shows how BGCtrls work: https://www.elecbyte.com/mugendocs/bgs.html#background-controllers And this section explains it a bit more: https://mugenguild.com/forum/topics/background-controllers-stages-170304.0.html These should be considered first because we can then hit the actual stage elements via AttachedChar's ModifyBGCtrl. Without the BGCtrls, we cannot affect stage stuff via AttachedChar. |
Beta Was this translation helpful? Give feedback.
-
This thread is for discussing the interface(s) for a currrently-hypothetical implementation of fully 3D, model-based stages in IKEMEN. This is continued from a brief conversation in the IKEMEN Discord.
NOTE: As of this writing these are merely discussions, no work has started on this to my knowledge and I wouldn't expect it to for quite a while!
File Formats
For an initial implementation, I think it'd make sense to stick with only one format, preferrably:
It turns out there are a LOT of standards for 3D model files. However, in my personal experience, it seems like the FBX format ticks most if not all of these boxes, and is quite common and well-understood by 3D modellers for other games that allow custom 3D content, such as VRchat.
For a more open and newer (but less commonly supported) format, glTF v2.0 may be worth investigating as well as it can also tick most of these boxes via the
.gltf
(embedded) format.Libraries
As a bit of an aside, I looked a tiny bit into Go's library ecosystem to see if someone wrote any parsers for 3D object files already. Turns out there's a couple:
Interface Proposal
The interface (no relation to GUIs or screenpacks or anything like that) refers to how end-users (specifically stage authors and editors) can tell IKEMEN to use a 3D model in stages. In other words, it's how the DEF file is written out.
Below is an example of how IKEMEN currently handles 2D sprites for stages.
This section declares a
BGdef
and loads a 2D sprite file,stage0.sff
, and then defines aBG
element to display it. There's a lot of additional parameters that could go there of course, but I stripped it down to the basics for simplicity sake.To differentiate 3D stages from 2D ones (and to no-doubt make parsing easier), My first proposal consists of introducing two new element labels:
3DBGdef
and3DBG
.First,
3DBGdef
specifies the model file in question to load. There should only be one per stage; below are three different versions depending on which format(s?) we end up supporting.Then,
3DBG
defines the model's location, scale, rotation, and so forth. It's hard to really make too many parameters here without deciding a format to use first (hence the lack of indexes for example; we're using the entirety of the mesh here!), but this should give you a basic idea of how it would work.Materials
Materials (how a 3D object is shaded and textured) are most likely already handled by whatever format we end up choosing. If for whatever reason we don't have a material (or the author just wants to use a uniform value different from the original mesh), I think that could potentially be exposed as parameters too.
For those who aren't 3D modellers, general consensus with just about every 3D model format is to use at least three values; these have different names depending on the standard and program, but going by Blender naming they are:
Coordinate Space
Now, there's a bit of a unique problem here. See, MUGEN specifications (and IKEMEN by extension) use pixel coordinates to position everything. X and Y coordinates are usually measured in the hundreds of pixels, in integer format like so:
start = 0, 185
However, 3D models by their very nature use much smaller float values, rarely exceeding
30.0f
on any given coordinate.Therefore, I think that when using models an internal multiplication of 100 should be applied to a given model's coordinates/rotation/scale, which should bring most models more in line with MUGEN's pixel coordinate values.
There's also the matter of how
localcoord
should factor into these models. Personally, I think it's best to simply ignorelocalcoord
entirely as it doesn't really make much sense for 3D stuff, but I'm curious for feedback on this part.Fighter Positioning
I think that the fighters should be aligned to Z-coordinate 0, and their behavior shouldn't really change at all from being in a 3D stage. The effect would look similar to Marvel vs. Capcom 2; 2D sprited characters moving and behaving on a 2D plane that just happens to be projected onto a 3D world.
HUDs and Explods
I haven't fully thought through how HUDs should be handled in this context. Maybe the HUD should just be drawn after the stage model is, effectively overlaying it on top no matter what.
Explods are a much trickier matter. Should they be rendered at Z=0 just like characters? But then how do you handle layering with any 3D stages that have geometry that covers up Z>0? Maybe determine where to render them based on their
sprpriority
value?Other
As you can probably tell, I got a little sidetracked while writing what was originally a post maybe five lines long at most. I probably forgot something while writing this monster, so please don't hesitate to ask if I need to clarify anything further!
Beta Was this translation helpful? Give feedback.
All reactions