Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
|
| ||
| Views: 20,054,263 |
Home
| Forums
| Uploader
| Wiki
| Object databases
| IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search |
04-26-24 01:17 AM |
| Guest: | ||
| Main - Posts by Apache Thunder |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 1/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
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.  )
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.
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.
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]](http://www.battlefieldsingleplayer.com/apachethunder/Images/other/MikuPeek.gif) ![[image]](http://www.battlefieldsingleplayer.com/apachethunder/Images/other/DivaMikuDance.gif) ![[image]](http://www.battlefieldsingleplayer.com/apachethunder/Images/other/Blank120x120.png)
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 2/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
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.
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.
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. ) 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?
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.
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. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 3/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
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...
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.  ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 4/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
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.
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. ).
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.
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. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 5/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
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.
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.
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. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 6/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
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....
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.
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. )
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.
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. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 7/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
Alright thanks for your input. I'll post something again if something else comes up. But for now that ends that current subject for me. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 8/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
Possible feature suggestion - Would you be able to add the ability to display the collision types by name instead of their id number when using the model importer feature (in the KCL section)? It would make it much easier to use. I have no idea what the collision types are and I'm sure someone posted about them somewhere, but it would be quicker for everyone if they are displayed in a manner similar to the objects in the object side of the editor. Unlike objects, there's probably only several different collision types unlike the hundreds of objects out there. So it wouldn't take long to build a simple database for that like with the object editor.
Also the ability to select/highlight faces by material. That way I can easily tell which faces the selected material is assigned to. It would make it worthwhile for me to fix the merged castle ground level I made if I can get the materials sorted out faster.
Perhaps a longer term goal is to merge/display the KCL model and the visible model in the same viewport.  ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 9/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
Well yes generally I'm aware of where some materials are on a mesh. But in 3DS Max, I had the mesh directly overlaying the visible mesh so I could see where things were.
Perhaps not as much of an issue if I created a whole new mesh and know what everything is as a result. But editoing/redoing existing meshes could be time consuming. Since the KCL just displays a wireframe this can sometimes make it hard to determine what a specific face is in relation to the rest of the map. I could tab switch out to different programs/viewports, but it could be time consuming on a large mesh. I enabled flat view in the KCL viewport, but there's no shading, thus all the colors blend together (since a lot of the materials weren't set yet) and I can't make out anything. Some basic lighting would help make the edges of different faces/areas more pronounced while not in wireframe view. As for overlaying the KCL mesh over the visible mesh. Having that in the main editor view port would clutter things up, that I agree with. What I meant was have the option to import/display the basic visible mesh in the KCL editor and the KCL is the only thing you can really interact with. Not sure where you had that test code in. Was it in the main editor view port? Then I suppose moving it to the KCL editor dialog would be more complicated and isn't something you want to do right now or perhaps the feature wouldn't be used that much.
If that won't work, perhaps instead of all that, you could improve lighting while in non wireframe view and enable the ability to select faces with the mouse. It would give me greater control and I can quickly fix material assignments or figuring out what material a specific face in the scene is without using the arrow keys to navigate down the thousands of faces until the correct one finally gets highlighted in the viewport. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 10/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
Yeah what I meant was the visible mesh could be displayed under the KCL mesh while in the KCL editor. Now when I said "basic visible mesh". I meant the mesh you see in the object editor, but without the lighting or objects being displayed. Just the basic mesh stored in the BMD of that level that you see while ingame basically. (but without all the objects as they aren't part of the mesh) Perhaps make it so it can only be made visible while in wireframe mode. (non fill mode) I could see making it visible with the KCL in fill mode to be tricky to do right and would indeed clutter things up.
But besides that, it seems that selecting by clicking and wireframe on top of fill mode certainly improves things a lot. Good to see that it's now a lot easier to look at. So at this point it wouldn't be a big issue if the visible mesh isn't shown. Once clicking on faces is working, I'd probably be satisfied with that. Meshes will always import with all the materials set to collision type 0, (so all the materials will have the same color). Now the wireframe on top of the fill mode will make things easier to work with. Then I can just click on a face and know what material it is and more quickly sort out which material went where.
Another thing I've noticed, it appears the shading of the mesh gets lost after export/reimport. (I'm talking about the visible mesh you see ingame at this point) Is there a proper way to add shadowing to a mesh and have it work when imported? I noticed that after I exported, edited, then reimported the Castle grounds, the darkened areas like the front doors, aren't darkened anymore. The entire mesh lacks any sort of lighting. Does Mario 64 DS use vertex colors for this or is it material settings that is getting borked by 3DS Max like with the transparency issue I was having? Maybe it's because OBJ might not support vertex coloring? If not, DAE export ability would be a definite long term goal if there's a enough folks out there that wants to edit existing meshes. Otherwise new levels might not have this issue if it's exported to DAE from the modeling program it was built in. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 11/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
On that note, don't forget to add partial transparency to any faces using the water collision type.
EDIT: One solution to the vertex coloring problem is to perhaps add the ability to alter vertex colors from the model importer or in a alternate mode in the main editor. It would side step the need to use odd ball OBJ plugins to export special OBJ files for them. Plus if done from within the editor, the results could be shown immediately and it would be easy to tell what it will look like ingame without constant re-imports and such. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 12/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
I think it does already. But the main issues is that normal OBJ files don't support vertex colors. He said in the dev thread that there's extensions to the OBJ format that can add that. I'm stuck with the standard OBJ exporter that 3DS Max comes with so no way to tell if the editor will import them correctly. Perhaps a better solution to this is allow us to alter the vertex colors from the editor. Perhaps while in the level mesh importer dialog or in the main editor with it's own editing mode button to switch to/from it. But I've already mentioned this in the dev thread. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 13/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
Posted by Fiachra Errr...what? I'm talking about alpha in the KCL viewer. It's cosmetic and doesn't impact any gameplay machanic. If you enable fill shading and for example created a fountain area, you won't be able to see the bottom of that fountain because the water collision faces above it will obscure it. I meant alpha in the faces while in fill mode in the KCL editor/importer. It wouldn't impact anything ingame as alpha on collision meshes have no meaning in SM64DS. It's not like I can assign textures to a collision mesh. Herp durp. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 14/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
Ok, I think vertex color importing is broken? I have attempted to alter vertex colors on some vertexes on stock Castle Grounds mesh using 3DS Max. I then export that as DAE.
If I import it, the wrong vertexes are colored. Not only that they just have rainbow coloring to them instead of shadows. So I'm not sure how the game applies vertex colors. Do the RGB values do different things in the game engine? That aside, the fact that the wrong vertexes come in with the altered vertex coloring is the main problem right now.
There's also Vertex Illumination. Not sure if that's used at all in the DAE format or in SM64. But I had one part of the mesh with just changes to the vertex illuminations. But it's hard to tell if it had any effect because the wrong vertexes get colored once imported back into the model importer. I had also managed to get 3DS max to bake lighting from radiosity renderer right into the vertexes using the Assign Vertex Colors toolset it comes with. I import that and the entire mesh has a rainbow effect to it. (maybe I should just screen shot this? )
EDIT: Ok here's screenshot: ![[image]](http://www.battlefieldsingleplayer.com/apachethunder/Images/other/BadImport.jpg)
I vertex colored the hedges, but once inside the model importer, the wrong areas had been colored. I reimported the DAE back into Max and the areas I intended to vertex paint are still correct, so something is going wrong with the way your editor is interpreting the vertex color assignments. These were the parts I had intended to color in Max: ![[image]](http://www.battlefieldsingleplayer.com/apachethunder/Images/other/VertexColors.jpg)
I had each hedge have only a single RGB value changed. One for Green, one for Blue, etc. I forgot to make one with all values changed equally. Perhaps the game just takes the RGB values literally and doesn't have any special effects. So for example, I make something look Purple on the mesh, it comes in purple. But the problem is, I lightmapped the entire mesh using Radiosity and applied that to the mesh right into the vertex colors. So each vertex has a value. It shows as shaded as I had intended in viewport for 3DS Max. However it comes into the editor with the entire mesh having that rainbow effect to it like in that screenshot. Looks like it will be impossible for me to light anything with Max because I can't even see how it's supposed to look once the vertex's are painted... ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 15/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
If you have a way of testing it on real hardware you should. If it does that on real hardware too, then it's a problem...if not then it's the emulators fault and you can ignore it.
Also got some more questions of my own. 1. What's the best way of deleting all the objects from a level. My first attempt at removing everything from the general purpose test map results in the game just freezing right before Yoshi would jump out of the warp pipe I placed on the map. (of coarse I put in a entrance and exit for that warp pipe) 2. What controls how the collision types behave? It appears it's different for each level. Material type 15 for example is grass in Castle Grounds, but on General Purpose Test Map, it's metal grate sounds. I think maybe it's got more to do with the sound banks. But on my merged castle grounds the water in the backyard area doesn't behave like water like it does in the backyard level. Instead it's solid and Yoshi walks on it as if he's Jesus.
I tried material type 3 (used by the water fall) and material type 2 which was what the KCL mesh for it originally had on backyards results in leafs effect on Castle Grounds. Is there a way to create a second water box on Castle Grounds? I may just have to do that, but the only water box/object on the map is the castle moat and that lowers when the pillars are pounded. Not something I want to happen to the water in the backyard area. 2. You know how to extend the level boundary of a map? Seems Hyrule Field is just too big and I can't go out very far despite the map having an updated KCL of the new mesh.
3. How do I make faces twosided? I noticed that when I reimported the Castle Grounds mesh, the fences were not double sided anymore. I could just create duplicate faces with reversed normals, but this is too inefficient to be doing on the limited polygons that the DS could handle. There's something in the material settings that I'm missing perhaps and is yet another thing Max is messing up. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 16/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
Site was down so a bit late on the replay.
Alrighty, here's the Castle Grounds mesh (this isn't the merged one I made, it's just the original unedited one with a couple of the hedges with vertex colors applied) Testmeshes.zip The second is a simpler mesh I created in Max. I hadn't really done much to it other then vertex color the small shapes. The big cylinder is suppose to have all RGB channels equally reduced. It was supposed to be darker as I thought darker RGB values when done equally, should result in shadowing the mesh. But instead I get the rainbow effect when it's imported into the editor. Same goes for the other meshes. The sphere, cube and pyramid have all but one RGB channel set to zero to emphasis each color. But the results also weren't as expected. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 17/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
I see. Yeah Max loves to fudge things up. Max also likes to include file paths for the texture files. Your editor isn't setup for that and throws up missing texture errors if I forget to remove the file paths from the texture entries (I had to do the same for the MTL files used on OBJ files). Aside from the vertex color issue, the editor imports them correctly for the most part. I just had to hand edit a few things. (I also had to rotate the model -90 degrees and reset the pivot or the mesh comes in sideways. I tried the flip Y/Z axis option on export, but it seems to have no effect)
Max does have a alpha value that could be adjusted for vertex coloring. Seems alpha is the root of all problems with Max right now. First with wrong alpha values on the material settings and now with DAE files being exported with non-spec alpha values for the vertex color data.
Max has some nifty lightmapping features I would like to try and export into Mario. One example, I could make a city mesh of some kind and have the light posts cast light and that would be baked into the vertex colors for the map or make a night version of Castle Grounds.
EDIT: Ok as for the messed up textures on my merged Castle Grounds...it can't be the textures causing this. I just got done importing Hyrule field from N64 Zelda OOT (yes you heard me right. ) and it shows up ingame exactly as intended. Though the game froze right before mario could emerge from teh warp pipe. But that may be bad entrance settings or something gone wrong when I removed all the objects from the test map I imported the mesh into. Either way, from what I could see, the mesh looks correct.
So I think something else is causing the messed up textures. I did not weld any vertexes with the zelda mesh, so perhaps if I break the vertexes on my merged map I might get it to work correctly? The Hyrule field mesh only has around 4000+ vertexes with 1600+ faces. N64 zelda models are surprisingly low detailed. I might be able to do a Legend of Mario mod if I wanted too. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 18/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
Most of the textures are "glitched". It's better just to show a screenshot. I did one better and uploaded a video:
http://www.youtube.com/watch?v=dNvBKKgMCmw It shows up correctly in the editor. It only looks like this ingame... Castle Grounds with my merged mesh shown first, then I warp pipe to the General Purpose Test map which had it's mesh replaced with Hyrule Field. That mesh works just fine and uses 50+ textures, while my Castle Grounds merged map only uses 30+ textures. Seems to me it might be too much polygons? I kept Castle Grounds under the 2048 face limit. It pegs in around 1800+ or so and I had already stripped out some things like some windows from the castle and removed a couple hedges as well as lowering the detail of the hills at the edge of the backyard area. Hyrule Field is only 1600+ faces. It has fewer vertexes though. Only 4500+ vertexes while Castle Grounds merged had 5000+ (but under 6000, as somewhere above 6000 hits a the limit the DS can use) I ran the game in a emulator and the textures showed up all black instead (with the few working areas showing up the same). It wasn't quite the same, so I instead recorded the video of it running on the DS hardware as I use that for all my testing anyways. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 19/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
That's strange, because the textures used on the castle grounds merged mesh are unedited and what the editor originally exported when I exported the model. I simply took the textures from the backyard scene and put them in the same directory so my merged version of both meshes would all the textures. Not only that Hyrule Field textures were 24bit after flipping them with a batch converter and they worked fine ingame. Either way, after converting all the textures to 256 colors (8-bit), the mesh finally looks correct!
I have some questions, but they are better asked in the help thread.
As for further suggestions: 1. Perhaps better new object placement. Every time I create new object and click on the map where I want it it almost always spawns underground and I have to move the camera down and drag it up. This consumes a lot of time. I understand that the mouse can only really move in 2D, but having it always spawn something I create on/near a collision plane would be better then having it end up somewhere way below where I intended. 2. Ability to select multiple objects. There's the global object offset feature I'm aware of, but there are many times where I want to select only a specific set of objects and move them and can't currently do that. 3. Ability to clone objects with a hot-key of some kind. (unless there is already such a hot key? Let me know what it is if that's the case) I guess I'm just spoiled from using Editor42 (map editor for BF1942), but quickly cloning objects with a key press would be very neat addition to this editor. It took me almost an hour to replicate the tree and Boo placement of the backyard area for the merged castle grounds mesh. I could have saved some time if I could just clone them instead of having to go and create new ones, drag them back up to ground level, set them into position and then set their parameter settings. If I could just clone them, then I only have to drag them into position. The way Editor42 handled it, was by selecting an object (or group of objects) and hitting insert key. This clones them. They always appear at the same height, but offset by a specific amount off the to side near the source object(s). Although my new Mac keyboard lacks a insert key, so it would be apprecieted that you not use insert key if you do add this feature.
4. The editor spits out an error when I try to delete all the path objects from General Purpose Test Map and get stuck with all but one deleted. I end up with an orphaned path object that doesn't show up in the side pane correctly and have no way of deleting it without the editor bringing up an editor. Might be why the map freezes when I try to play it afterwards since I can't get rid of all the path objects. The ability to select multiple objects might fix this if I'm able to delete them all at once. 5. Ability to "remove" all objects on a level at once. Basically clear it out. I'm not sure if there's something already in the editor that does that, but being able to wipe a level of all objects would be great since many modders just end up replacing the level geometry and would end up placing new objects anyway. That's all I can think of at the moment. More might come as I use the editor more. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 15 Posts: 20/38 EXP: 14222 Next: 2162 Since: 03-23-14 Last post: 3601 days ago Last view: 2279 days ago |
Cool. Was able to assign material 19 to Water 1. My new mesh doesn't use a lot of the materials in the CLPS anymore, so changing 19 to Water 1 wouldn't hurt anything. So now the collision planes on the star fountain thing in the backyard section now behaves like it should.
As for the CLPS Dialog: ![[image]](http://www.battlefieldsingleplayer.com/apachethunder/Images/other/CLPSDialog.jpg)
I know what the number on the very left means. That's the material number and the very last setting on the right sets what type it will be. But what do all the other numbers do? They aren't labeled.
I still can't remove path nodes or paths without the editor spitting out an error at some point and being left with either being unable to delete any more or from them all vanishing from the side bar despite still being on the map. Is there a way of deleting them? I want to clear out General Purpose Test Map so I can use it for other things like testing my Hyrule Field import.
____________________
I have cameras in your head! |
| Main - Posts by Apache Thunder |
|
Page rendered in 0.096 seconds. (2048KB of memory used) MySQL - queries: 21, rows: 137/137, time: 0.009 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |
