Kuribo64
Views: 19,854,735 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
03-29-24 06:57 AM
Guest:

0 users reading SM64DS Editor Help Thread - Post your questions here | 1 bot

Main - General SM64DS hacking - SM64DS Editor Help Thread - Post your questions here Hide post layouts | New reply

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 62 63 64 65 66
skawo
Posted on 03-21-14 01:25 PM Link | #39546
6400 polygons definitely will not work without any glitches on real hardware.

Cackletta
Posted on 03-21-14 04:12 PM Link | #39550
It sure did. I tried it on my gateway NDS, also I used 4 textures, that small amount of textures could have reduced the complexity.

____________________
Subscribe to my youtube channel
Follow me on twitter
My Modification's progress thread here

skawo
Posted on 03-21-14 04:14 PM Link | #39551
Then either you don't have 6400 polygons or you've made your level in such a way they never end up all on screen. Else, they'd start disappearing.

Fiachra
Posted on 03-21-14 05:44 PM Link | #39553
If you texture all of those faces and create a collision map with that many faces (or probably over 3500) that level won't work. For a model with no textures and no collision map you can import around 8000 faces but there's be no point.

Cackletta
Posted on 03-21-14 06:45 PM Link | #39555
Although all faces were textured, but the whole level can't be seen from the sky, so maybe because of all polygons aren't displayed at first sight.

____________________
Subscribe to my youtube channel
Follow me on twitter
My Modification's progress thread here

Fiachra
Posted on 03-21-14 07:25 PM Link | #39557
The DS will only ever display 2048 polygons at a time, this is even more noticable on a real DS where you'll see things like the player's head disappear when you move the camera.

Cackletta
Posted on 03-21-14 07:39 PM Link | #39558
I didn't notice any identifiable glitch on my DS, I could also remember rippping a mario kart ds model with 7000 polys, Mario kart is advanced, just like in sm64, it only supports 32x32 texture, other N64 games could handle 64x64, that's my findings, maybe you slightly mis-matched a polygon count.

____________________
Subscribe to my youtube channel
Follow me on twitter
My Modification's progress thread here

Fiachra
Posted on 03-21-14 08:13 PM Link | #39561
I'm not saying you can't have a 6400 polygon model, I'm saying that if it's fully textured (to look good) and you want a collision map that closely matches the model, that many won't work. As a guide, my SMS models are all around 4800 - 5100 faces with collision maps with around 4200 - 4900 faces.

NoThisIsStupider
Posted on 03-21-14 10:46 PM Link | #39564
Through much testing, I discovered I forgot to delete the texture animations on my fresh rom :(
Well it's working now, i'll modify the model and have the hub for my hack complete.

____________________
Switch on latest firm happily playing Smash daily
PC with an i7-4790K, RX480, 16GB ram
Various other consoles that are hardly used due to emulation existing

Apache Thunder
Posted on 03-23-14 08:01 PM (rev. 9 of 03-23-14 09:56 PM) Link | #39592
Alrighty, registered up and all that business so I can take a try at doing some mods for this game now that I got a Nintendo DS again to play this on. (For this particular gaming console, the emulators didn't suite me well as the touchscreen experience is lost on the PC. :P )

So my question here is....What settings work best in 3DS Max when importing/exporting OBJ files that this editor uses?

My initial test run was to edit the castle grounds level geometry. I had did a quick test by "merging" the castle backyard to the rear of the castle grounds. I didn't do anything fancy yet. Just deleted some overlapping polygons. I didn't change the collision geometry yet as I was first trying to get the visible geometry to work before I got to that.

The main issue is, I import the merged level geometry and it appears to import correctly. BUT most of the level geometry is invisible. About the only thing that isn't is the water fall geometry. (I put the merged OBJ file into it's own folder with all the textures each one used. (I did not overwrite existing textures when I copied them to the folder from each OBJ folder respectively. I kept each exported level in their own folder by the way.)


I didn't go as far as test it in game yet. I assume since it appears like this in the editor that it would appear invisible in game as well.

I am using 3DS Max 2010, but have Max 7 and Max 13 as well to choose from if there is a particular version this is better suited for.

I'm aware that most folks here seem to be using Google Sketchup or Blender, but I did all my game modding from Battlefield 1942 using 3DS Max, so that's the program I've invested the most time in learning and would like to just do my level editing/creating using that instead of having to relearn a new program. :P

To show you what I've done with Max, here was levels I ported from one game engine into a completely different one. I did all of the level layout and lightmapping using 3DS Max:

http://www.youtube.com/watch?v=v6V3bU_rz-s

I have at one time a few years back did a little experimenting with Mario 64 DS. I imported a edited mesh I created when I was also experimenting with importing geometries into the N64 version of the game. Here's what it looked like:

http://www.youtube.com/watch?v=h2GNC4DF8yA

And here's the N64 version that gives you a better idea what it sorta looked like as in the video of the DS version, I couldn't explore it very well due to bad collision mesh detection.

http://www.youtube.com/watch?v=b2MxSUbK2PA

Being that all that was done a few years ago, this was back when the collision mesh generation for the custom levels was limited and very buggy for SM64DS so I had dropped doing anything further and Toads Tool for the N64 version just wasn't user friendly for me and the game was too limited in terms of adding new objects and such where as the DS version was more flexible.

SM64DSe seems to have solved this now so I want to give this another try. :P

So long story short it appears I'm doing something wrong when exporting (or importing) the OBJ file. So textures aren't getting assigned or the materials are getting messed up...

The last time I imported a mesh into Mario 64 DS was a few years ago and the import feature of this editor was quite different. That and I had long forgotten what I did to make the mesh work. (collision issues aside)

EDIT:

Also noticed that the Castle indoor maps don't import correctly at all. Is it perhaps due to the "bones" system now used by the editor? There's an additional .bones file for OBJ files exported. I suppose the Castle Grounds doesn't really make use of it, so it imports correctly, however the Castle 1st floor does.

I am aware that the bones is used to determine "areas" in a manner similar to the room system in the N64 version. Except that it works a bit better. But I am thinking the OBJ importer Max comes with doesn't know what to do with it. :(

____________________
[image][image][image]
I have cameras in your head!

Fiachra
Posted on 03-23-14 10:58 PM Link | #39594
If the polygons are appearing as invisible it could be that the material is defined as having a transparency of zero within the .mtl file.

I've never used or am familiar with 3DS Max so I can't really help you much with that though the editor should be able to import any valid OBJ model. Your 3D editor should be able to handle the "o" command in OBJ models when importing and exporting, some don't which will cause any separate bones to be merged into one when exporting.

The editor also now supports importing DAE models.

The bones system works by splitting each model into different bones based on the "o" command in OBJ or the tag in DAE. The bones system is explained here:

http://code.google.com/p/sm64dse/wiki/ExportingAndImportingModelBones

For the Castle 1st Floor I've had trouble with it before, I think I was able to re-import the model into a different level but not the original, didn't look into it much.

Apache Thunder
Posted on 03-23-14 11:11 PM (rev. 9 of 03-23-14 11:47 PM) Link | #39595
Yeah a options dialog comes up when I go to import a OBJ file into max. Since it doesn't show any settings that relates to bones or animation like vertex weighting, I would have to assume Max doesn't support the O command thing. I would bet there's third party OBJ scripts for Max that might. Perhaps I could look into that if I ever feel up to changing the Castle indoor levels or want to do anything with the bone system. :P

As for the materials I can check the MTL files for that. If that's the case it wouldn't be too complicated for me to make a work around for that. As far as I can tell everything is still in the right place, so Max didn't screw up the scale or rotation. (the water fall mesh was still in the correct place)

It's disappointing that I couldn't import the Castle Indoor stuff into Max directly. I wouldn't mind having to import it without the bone system as I could use the the Castle Grounds/Castle Floor maps in a different game engine that doesn't rely on it. Looks like maybe going to have to import into Blender and export into something Max can use or find a third party max plugin/script that has better OBJ implementation.

Never worked with the DAE files before. Not sure if Max can work with them. But the level editor doesn't appear to support exporting to DAE format from what I can tell, so I see no point in trying to use DAE if I want to work on editing meshes that use the bone system. If Max can export to DAE, that might be a better route for me for Castle Grounds and other levels that don't use bones.

EDIT: Silly me. Looks like DAE is native to Max or something. It's got import/export support and appears to share similar features as the FBX files. :P

Perhaps in the future the editor can have the option of stripping out bone information for levels like Castle Floor. For me anyway, it would be easier simply rebuilding that system upon export. I've vertex weighted things way more complicated (My Mario Kart Mod for BF1942 for example, has a ton of animated meshes in it and they got more polys in them then entire M64DS levels. :P ) then these low poly Mario meshes for the DS, so it doesn't appear to be complicated if it's anything like vertex weighting which is something I'm used to doing in Max. Unless I'm completely misreading what purpose the bones serve in Mario 64 DS? :P

I'm aware that Meshes like Peach and Mario would use them, but perhaps it's a little different for level geometries. Obviously the big difference would be that level geometries wouldn't be animated like character models and would instead use the bones to define rooms. Sorta like the LOD system of BF1942 where objects get removed based on distance using distance selectors and stuff. Using bones is sorta of odd way of doing something like this, but I guess that's what Nintendo had to work with for the hardware at the time. :P

EDIT:

Ok using DAE instead nets me worse results. I exported to DAE using Max and trying to import it results in nothing at all showing in the import preview. I did make sure to remove the file paths that Max was adding to the texture references in the DAE file which got rid of the missing texture errors. But aside from that the mesh still appears invisible (not even the waterfall shows this time). No errors came up so something else is going wrong with the DAE files. :(

Also which string in the MTL files handles alpha? I'm not seeing it. Perhaps it's the "d" string as the water material has a value for that matching the opacity level for it in the material that I viewed in Max. So perhaps it's that command that handles it. Most of the other materials have a value of 1 so if that's the case they shouldn't be invisible. Unless Max is getting the number wrong and it should be 0 instead?

Code snippet from MTL file:

newmtl water_mat
Ns 0.0000
Ni 1.5000
d 0.4824
Tr 0.5176
Tf 0.4824 0.4824 0.4824
illum 2
Ka 0.5176 0.5176 0.5176
Kd 1.0000 1.0000 1.0000
Ks 0.0000 0.0000 0.0000
Ke 0.0000 0.0000 0.0000
map_Ka water.png
map_Kd water.png

The "d 0.4824" value appears to be the opacity level for the material. Most of the other materials have a value of 1 so there's nothing jumping out at me that appears to be the cause of the invisible materials.

____________________
[image][image][image]
I have cameras in your head!

Fiachra
Posted on 03-24-14 07:33 AM Link | #39598
The .bones is not a standard OBJ feature, it's specific to SM64DSe. It doesn't control how the model gets split up, it just contains parameters to be written for that bone to allow defining things like hierarchy and SRT values used in animation. If there's no .bones file found the model will still import with all bones given default values. If you want a mesh to be imported as one big bone you can comment out or delete "o" commands within the OBJ file.

OBJ doesn't support things like vertex weighting, that's why the custom .bones system is used. Vertices are assigned to bones based on the "o" or geometry tag they're in, hopefully someday they'll be assigned per vertex instead using DAE's bones system.

The "o" command is a standard OBJ feature that allows splitting the mesh into smaller chunks.

Transparency is defined with either "d" or "Tr" within the mtl file.

It may be easier if you just send me the models exported from 3DS Max.

Apache Thunder
Posted on 03-24-14 04:32 PM (rev. 4 of 03-24-14 04:44 PM) Link | #39601
Oh I see, basically the bones files just sets up which sub object in the OBJ file goes to which area as defined by the bones file. The O command just defines part of the mesh is a sub object or not. I believe Max supports the O command as I have worked with other OBJ files that had sub objects in them. (Max has the option of importing the OBJ as a "merged" object or not. I assume this means Max does read the O command and can be told to ignore it if needed.)

But the odd thing is, the 1st floor mesh comes in all messed up when I import it. Sorta like how an animated mesh with a missing skeleton gets all distorted ingame in BF1942. But I think something else unrelated to the bones file is going wrong on import perhaps....

Here's the object files you requested. It appears the "Tr" command is set to zero on just about all the materials. The only material where it isn't is the water material used on the water fall. This perhaps is the command I was looking for. For some reason Max decided it was a good idea setting this to zero... :P

I'll set them all to 1.0 and see what happens. But nonetheless here's the files you requested anyway. I also included the exported DAE file as well.

DAE files come in completely invisible. I think something else is going wrong with them...

CastleGrounds_MergedTest.rar

EDIT:

Yep it was the Tr command that Max got wrong. Set them all to 1 (except for the water materials) and now it comes in correctly in the editor. :D

____________________
[image][image][image]
I have cameras in your head!

Fiachra
Posted on 03-24-14 07:58 PM (rev. 4 of 03-24-14 08:01 PM) Link | #39602
I don't know why 3DS Max gave "d" and "Tr" different values, they're supposed to be the same thing, I believe "d" is the official one.

The problem with the DAE model was the same thing, the transparency for all of the materials was set to zero, DAE has two similar-looking tags within the effect element for a meterial, "transparent" which gives a colour and "transparency" which gives a float value like the "d" option in OBJ - this is the one that the editor uses when importing, "transparent" is ignored.

I really don't know why 3DS Max can't handle the exported Castle 1st Floor, it's a valid OBJ model, Blender and MeshLab can load it fine. Does it make a difference whether or not you select to merge it on import?

Edit:
The DAE model is also rotated 90 degrees on its X-axis, DAE does have an "up_axis" tag, I may update the editor to use that if present.

Apache Thunder
Posted on 03-24-14 09:13 PM (rev. 3 of 03-24-14 09:22 PM) Link | #39605
Nice, if that's all that's wrong with the DAE files then I might use those at some point too.

I finished doing the final merged Castle Grounds mesh and it came out looking nice. Managed to get it to exactly 2024 faces total. Not sure what the limit is but I heard 2024 or 2048 was the limit before problems come up.

I did have to remove some polygons in some areas to make the new mesh stay under the limit. (all I had to really get rid of was the recessed wall the rabbit is in on the Backyard area and reduce the amount of polygons the hill areas on the backyard areas used. After that I had it under the limit)

The rabbit for the backyard can either just be moved to the new roof area that was added or omitted from the Castle Grounds entirely and only show up if the Backyard area is entered from inside the Castle. I might do a partial merge of the Castle Ground into the Backyards level so they both at least look consistent since I can't have all of the backyard stuff in the Castle Ground level due limits with the object banks. So there will still be a separate Castle Backyard level.

Will try and figure a way of allowing Mario up onto the roof area to get the rabbit at his new location. Probably just throw in a climbable pole or something. :P

Here's a couple images of what I've got done. The only thing left is to do a proper collision mesh (will likely just let the editor generate one, then export the KCL file to OBJ so I can overlap them in the Max scene and set up all the materials and remove unneeded polygons. :D ).

MergedCastleGrounds.jpg

Found a minor issue with the uvmapping. It came imported into max already looking like this (even before I edited the mesh)

MinorUVMapIssues.jpg

I might be able to just redo the uvmapping for the effected areas. Annoying but manageable.


Another UV mapping bug is the Peach portrait and a few other textures shows up upside down in Max. But it seems to only effect how it appears in Max. Once the mesh is imported back into the level editor, the effected textures still look normal. It's only the issues with the sand areas that shows up in the editor (and I assume it would show up ingame like that too since the original mesh as viewed in the editor didn't have the textures all messed up like that.)

Thanks for the help. Hopefully I can make something useful for this. :D

EDIT:

Got the 1st floor to import correctly! I had to check the "Import as single mesh" option. Even though only one object group showed up in the object list in the pre-import dialog box. Whatever. It imports correctly now, so I can mess with the 1st floor if I want to. :P

____________________
[image][image][image]
I have cameras in your head!

Stomatol
Posted on 03-24-14 09:21 PM Link | #39606
That looks really good! I wonder why they didn't merge them together in the real game

Apache Thunder
Posted on 03-24-14 09:23 PM (rev. 11 of 03-25-14 04:04 AM) Link | #39607
Maybe they didn't want to push the DS to it's limits quite yet being that this game was a launch title.

The merged mesh comes just under 2024 faces. Maybe Nintendo didn't have time to rework the object banks. That's probably the main reason. :P

But this makes even less sense on the N64 version as the N64 could probably handle more polygons and such. Perhaps they just didn't think to do that since and never bothered doing it with the DS version.

I think limits with the object banks was most likely the reason for them staying separate. I can probably have the original warp points and trees in the merged version, but the Boos and the extra rabbit might not work with the Castle Grounds object bank. Won't know till I set up the objects in the editor. :P

EDIT:

Alright, the KCL editor is just too limited for me at the moment for me to do anything useful. I would have hoped that it would have saved collision types based on material settings since I edited the original collision meshes and merged them. However the importer doesn't bother to associate materials to collision types on it's own. I would have to go through all 20+ materials and find out which goes to which collision type and reassign the collision types.

The way Max handles merging multiple meshes that use conflicting material ID numbers is to create a new material ID for the conflicting faces so they can preserve their material settings. However Max isn't terribly smart about this. (Max doesn't merge materials even if they share the same settings, and even if it does, it misses too many still resulting in a lot of duplicates) thus I end up with 20+ materials after merging the two collision meshes. I just can't be bothered to really fix this as I would either have to redo the materials or try and figure out which material goes to which set of faces on the mesh. :(

Future feature suggestion is find some way to save collision type in the material somewhere. Perhaps the diffuse color or some other standard parameter could be used. Don't use material names though as that would not remain consistent if multiple meshes get merged together.

If anyone wants the mesh I made shoot me PM and I can give it too you. Just be aware that you'll need to setup the materials. Max ended up assigning 20+ materials to the merged mesh for the collision and I reset them all after I found that the OBJ importer in the KCL importer made no attempt to restore collision types, so you'll need to set up the materials in your modeling program and reexport. In it's current state I did set up the water materials to the correct collision type, but everything else is collision type 0. :P

____________________
[image][image][image]
I have cameras in your head!

Fiachra
Posted on 03-25-14 06:07 PM Link | #39611
The polygon limit for SM64DS models is around 5000, 2048 is the maximum amount that can be displayed at any one time.

The "UV issues" isn't a bug - OBJ does not support all the texture options that BMD does, there's no way around this.

I don't understand why you're exporting the generated KCL and re-importing it and not just importing the same model or a slightly modified version and setting the collision types per material then. Setting the collision type based per material when importing is the easiest way to do it. I would definitely disagree that it's "too limited".

Apache Thunder
Posted on 03-25-14 06:15 PM (rev. 13 of 03-25-14 06:38 PM) Link | #39612
Well in my case I was merging two existing meshes. The backyard and the castle grounds. The existing collision meshes were already optimized so I thought it be easier to merge them and edit the connecting areas to match. So now I got one big collision mesh, but with a bit too many materials. I had thought the KCL editor saved collision types somewhere in that material info which was preserved on both meshes. But that's not how things turned out so at this point I don't really want to redo the mesh again. :(

I can use the ones the editor generates. but it doesn't create the walls and ceiling that the original had. Which would probably mean Mario would fall off the map when using the cannon.... :P


Also, the merged visible meshes have nearly as many materials as well. So it would not really be any faster to use that.


Also last night I finally got around to testing it on my DS and it appears with the textures all glitched up with slight sound distortion. Something tells me there's too many textures it's trying to load/running out of texture memory? I didn't see any vanishing polygons, so I know it's not the mesh it self causing it. Must be the textures. :(

Starting to see why they chose not to merge them in the official version. Maybe the amount of materials on the mesh could be causing it. Is there a limit to how many materials there can be on a visible mesh? May just be Max's habit of making too many materials on merged meshes that's the cause here. :(

I'm guessing Blender/Google Sketchup might be better at merging stuff without creating too many new materials as I have not seen this be a problem for anyone else. Then again, most folks here are making new level geometries and aren't really fiddling with the existing ones. :P

My mind is geared towards expanding existing content. I'm not too great at creating new level designs. I guess too many different factors for me to keep track of and likely couldn't have the same amount of variety the original had. My main plan was to add more warp pipes and create "underground" levels which was something Mario 64 lacked compared to the original 2D sidescrollers from the SNES/NES days. Basically expand on the existing plot of the game. I could create a new one, but it would be sub-par because as I said, I'm not a very artistic person. Which is why most of my modding work in BF1942 involved porting things from one game engine into another. Though I did create a couple of new levels near the end. Like this map for BF1942:

http://www.youtube.com/watch?v=kS5kD_H2rVw
(note that the city blocks are existing content I got from a site that provided them royalty free, so no I was not responsible for the building meshes. They came in preset city "blocks". I did arrange them my self though, so the layout of the city was my doing. :D )

I chose this one since it had some Mario related stuff dropped in. That brick block and Mario question block mesh was made from scratch in Max by the way, so I do have the capacity to create new models. :D

Had I got for enough along with this perhaps even add a breaking brick block. But not sure what this game can handle in terms of new objects being added, so just random ideas I'm spouting out right now. Though I do know that the brick block I made for that video shown above is probably too high poly to be used as a recurring object in this particular game. :P

____________________
[image][image][image]
I have cameras in your head!
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 62 63 64 65 66

Main - General SM64DS hacking - SM64DS Editor Help Thread - Post your questions here Hide post layouts | New reply

Page rendered in 0.066 seconds. (2048KB of memory used)
MySQL - queries: 28, rows: 144/144, time: 0.014 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.