Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
|
| ||
| Views: 14,036,526 |
Home
| Forums
| Uploader
| Wiki
| Object databases
| IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search |
04-05-21 11:38 PM |
| Guest: | ||
| Main - Posts by Apache Thunder |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 21/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Oh. So basically the far right setting is really just a "preset" that auto sets all those numbers? Entering custom values (that didn't match up to a known preset) would cause the type on the right to go to "other". Makes more sense now. As long as I keep to the presets on the right, I won't have to worry about them mysterious numbers.  ____________________ ![[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: 14 Posts: 22/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
I had tried that. I get this error once I try to delete the last path node:
So once that happens, things start to go wrong. 
I had deleted the path nodes starting with the last ones, then moving up. Once I get to the "PathPointObject 0". I get that above error. I'm able to still delete the other path objects, but have no way of getting rid of PathPointObject 0. Altering what order I delete them in doesn't help. It errors at that specific object.
(I'm using the US v1.2 rom by the way) ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 23/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Yeah, perhaps a custom General Purpose test map was what I tried Hyrule Field in. I would keep walking off towards the center of Hyrule field, but get stopped right before I get close to the Lon Lon Ranch entrance. Seems I hit a global boundry of some kind? Odd I would run into that since you said SM64DS doesn't have a limit like that. SM64 for the N64 did I recall. I know for a fact my collision mesh didn't have anything obstructing Mario/Yoshi. The invisible wall I hit seems to be flat and straight. There isn't any areas where I can go further. Its a straight line right through the entire field and I can't go past it. So I had thought it may be a global map boundry of some kind. What's the polygon limit for collision meshes? Perhaps I had too many polygons for the KCL since I had to leave part of the original collision mesh for the test map mesh since currently couldn't remove the existing objects due to the path object bug. So leaving that in and offsetting Hyrule field off to the side was what I did. I'm 100% sure I offset the KCL for Hyrule too since if I didn't I would see Yoshi walking through hills and areas as if they weren't solid. But he follows the terrain correcly, so the alignment seems to be correct. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 24/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Thanks for all your help. I was able to get vertex coloring to work after manually removing the fourth set of vectors used for alpha. Though it took me like 20 minutes to do this, although I later found a quicker way of doing it by using Notepad++ and using column feature to tack on a unique set of letters to the end of all the numbers in the fourth column, so I could then use the standard find/replace feature to quickly remove the fourth set of numbers. Wish I had tried this earlier... 
After that, it all works as intended. Video of the final result. This time from an emulator hacked to run at a higher internal resolution, so no more super pixellated madness. (toggle HD to really see the improvement )
http://www.youtube.com/watch?v=rJntLVtiSpw The lighting was just a quick render out of Max, I had not done any touchups to it yet as some areas are darker then they should, but already, they are a ton better then the flat no lighting mesh I would otherwise get if I had stuck to using OBJ files....Mods like Star Road need vertex coloring in their levels (though some of Skawo's work might be making use of vertex colors. Hard to tell from just the screenshots. But Star road definitely seems to lack it). It would really make them stand out. But it can be a tedious job if they are stuck with Blender and lower end apps. I've been too spoiled by all the features of 3DS Max from when I was modding BF1942. I never really learned how to use Blender and Google Sketchup. I can't imagine how limited their lightmapping capabilities might be. Vertex shading would likely have to be done entirely manually in those editors.
The only minor issue left is the tree shadow textures. I can't get any alpha in them working like the original. (I did indeed check the transparency setting for the material in the DAE file and the water material works fine....). If I try to import the mesh with the tree shadow texture up-converted (since I had to convert all textures to 8-bit 256 colors like you suggested) the game freezes when trying to load the map. Seems I'm stuck with this for now. I could just remove the tree shadows. I changed the textures used on the sand road to get rid of the broken UV mirroring issue due to OBJ file limitations. Everything else worked fine though.
Very odd that I didn't have to do anything to the textures used on Hyrule field (and they had even been unconverted to 24bit since I had to use a batch converter to flip them vertically) and that the untouched textures exported from the unedited Castle Grounds/Backyard from have to be reconverted for them to import correctly....Seems like the editor's texture conversion/import routine might need some further improvements. But for now I'm satisfied with it. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 25/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
I see. It might not be a problem once I get the mesh centered. But I'll need to remove all the objects from the test map first. I'll wait till the next editor release before trying. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 26/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Perhaps the issue is that the inside castle area made use of areas (the bone system in SM64DS).
Does your level use bones? If so, something may have gone wrong with that on import or you didn't set them up correctly. Depending on how complex the model is, you might be able to get away with not using them at all. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 27/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Have you tried importing it into one of the two test maps (Tox Box Test map or General Purpose Test Map) and seeing if it works there. If it does, there's something in the original Inside Castle level that isn't working with your new mesh. Perhaps the Inside Castle areas require area separation even if model isn't complex enough to warrant it.
I checked the texture animation settings for Inside Castle (1st floor) and saw nothing set up. But it does list 8 "areas" so perhaps the fact your mesh isn't divided into 8 areas like the original is causing problems even though there isn't any texture animations set up. You may either have to use a different level slot for your new mesh, or try setting up 8 areas with the bone system. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 28/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Ok, I just now edited and re-imported the existing 1st floor mesh without the area system setup. (basically imported into Max, used multires to get it under the 2048 face limit. The level format can use more and outdoor levels can get away with it, but this indoor mesh going above that could cause issues since a lot of the mesh could be rendered on screen at once due to the confined views allowed in this level)
After all that, It appears that the editor isn't removing parts of the previous mesh (the first room aka the room you enter when you enter the front doors from the outside doesn't seem to be effected. All the other parts that used to be in separate areas don't get removed correctly it looks like). For example, I removed the window glow faces from the fish tanks, yet on re-import they are still there. There's also some major z-clipping with with a grey mesh overlapping the existing mesh. Thus, I think the original area system isn't getting erased properly and I end up with parts of the old mesh still in the level (but without texture assignments). Thus most likely what you are seeing is the DS (or emulator) lagging and not rendering correctly, because there's way too many faces on screen at once due parts of the old mesh still being there. What does your mesh look like in the editor? Image of what it ended up looking like in the editor after I imported my modified mesh: Something is definitely going wrong here. My modified mesh appears to be as intended (and zero issues when I viewed it from the model import dialog) Ignore texture UV errors, that's just from a quick multires in Max, as this was just a test to see what happens when removing the area system) but there's portions of the old mesh still here. Plus when I go to the texture animation dialog, it still lists 8 areas even though I completely removed them.... At this point I recommend using different non area based level slots for your new castle indoor levels. Would be more hassle then it's worth to change the indoor castle levels as the editor "might" be bugged in this respect anyway, so it may need a future revision release to fix this. EDIT: Now that I think about it, I didn't touch the collision mesh at all. There might be special collision materials that is triggering this. Did you remove all the collision types in the CLPS and create new ones? You might need to do this with your new mesh since it likely won't be using all those special materials. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 29/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Oh I see. I went ingame and noticed most of the level is invisible (I had already fixed the transparency issues in the DAE file). When I enter the fish tank room, it becomes visible and the first room I was in that was visible becomes visible for a quick moment as I am about to re-enter it from that room. Looks like it will just keep malfunctioning unless I disable the whole room system thing going on in this level. (might just be either the door settings or the collision mesh?) ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 30/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
I removed the bone system. So the whole mesh was suppose to appear as one (since 3DS Max doesn't support importing OBJ files with bones). I exported as DAE since I had also decided to vertex color it. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 31/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
You need to create a collision mesh for it. The editor has the option to make one based on the visible lod upon import.
But it sounds like you might be using an old outdated version of SM64DS. The old 2.0 betas had major bugs with the collision mesh when importing and compared to the current version is pretty primitive in comparision. So you need to make sure you are running the latest version since the option to use a copy of the visible mesh as the collision is on by default, so you shouldn't be having this problem, so it definitely sounds like you are using the wrong version of this editor. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 32/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Looks like you have some water going through that level....So how about "Koopa Gorge".  ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 33/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Posted by Cackletta Well when I said Blender and SketchUp app is more limited, I meant that you likely can't do any automatic lighting of the vertexes using light sources and such and thus have to set each vertex manually. Max has a feature that lets me bake Radiosity solution lighting from the lightsources I place in the scene to the vertexes via a "Assign Vertex Colors" modifier. It's a bit finicky and isn't perfect, but I don't think Blender has anything close to this. I have been able to get working vertex colors by removing the last set of numbers on all the vertex color vectors. Example from a normal DAE from Max: <source id="default-lib-VertexColors0">
<float_array id="default-lib-VertexColors0-array" count="4116"> 1.000000 1.000000 1.000000 1.000000 That last 1.0000 on the very right is the "alpha" value for vertex coloring. Thus max uses RGBA for for this array. However both the editor and the DS hardware doesn't support full RGBA. Only RGB (thus no alpha in vertex colors). Currently the editor wasn't coded to correctly intreprete/remove the fourth number on it's own, so it causes one of the channels to get swapped/left out when it shouldn't. This results in a rainbow like effect on the entire mesh or parts of the mesh that was vertex colored. Sounds like your problem is a bit different. Does the game engine allow vertex coloring on partially transparent meshes? Is the water plane on your mesh part of the mesh or was it added to the level as an object? (like for example the castle moat water which is an object and not part of the mesh) EDIT: Ok looked back on my video of my vertex colored Castle Grounds level and the lighting of the water fall (and the water in the backyard area) is vertex colored properly as was set from my Max scene. On top of that I completely forgot about the tree shadows. They are separate faces on the level mesh with their own material settings. (not separate objects, just not welded to the rest of the mesh) Those infact uses all white circle shape in the texture file it uses and the material for it has it at a partial transparency level. Vertex colors and/or the material colors is what makes the shadows appear black. I don't think tree shadows are the only thing in this game that relies on material settings to give something color. Not sure what's going wrong with yours. Perhaps Blender is doing something wrong or somehow the water mesh has it's own vertex array or something? Did you check to see if there's more then one vertex color array in the DAE file? I don't know if DAE file supports more then one or not. Perhaps it's mainly for multi-object DAE files and somehow your water mesh got saved as a separate object or you forgot to merge it if it was created separately in the editor. Also, I always use "Export Selected" when going to export a mesh from Max to DAE. This ensures no other objects gets included into the DAE file and keeps things to spec for the most part. Perhaps you have other things in your scene that you didn't intend to include but it got exported with it, since you used the general export option instead. Blender may have a similar option, so check for that next time you go to export the scene. EDIT: Looks like the level boundry also applies to objects as well. I tried to place a object past where the invisible wall is and it seemed to work. (as in, the editor displays it where I put it). But if I close the level and open again, the object ends up at -32 (or a lower number depending on how far off the boundry I put the object), so the object effectively wraps around to the other side. So it looks like a global memory allocation limitation and/or how it stores object positions and since the player character is considered an object, the game can't place the character or track it beyond this position limit and thus the invisible wall. It may be a limitation in how the object storage format handles position data, but seeing how it happens ingame too, it seems like a global type thing. Might even be 32bit/64bit related. The position limit occurs right at 32. If I place an object in the editor beyond 32 on the Y axis for example, it would wrap to the other side as a negative value. Example, I put 33 in, reload the map, it shows up at -32. Probably not something the editor can fix. Might need a rom patch of some kind to fix this.
However some good news (for me anyways. ) that after centering the Hyrule Field mesh, the explorable areas won't be beyond the 32 mark on any axis. Hyrule is pretty much the largest in area size of just about all the Zelda levels, so if this one fits, all of them well. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 34/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Here's some name suggestions for the mod off the top of my head:
Super Mario Star Dust Legacy Super Mario Road to the Stars Super Mario DS Land Super Mario DS World Super Mario Dual Stars Super Mario Star Path Super Mario Power Land Super Mario Universe (Land then World, then Galaxy, now Universe. )
Super Mario Star Universe Super Mario Planet Super Mario Star Planet Super Mario Secret Stars Super Mario Stars Reborn Super Mario Spirit Road Super Mario Spirit Land Some crappy, some might exist already, I didn't check. Just listing off things I could think of quickly. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 35/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Partial alpha textures freeze the game? The roads in my Hyrule Field test port have partial alpha and haven't gotten freezes from it. At least not when used in the General Purpose Test Slot:
http://www.youtube.com/watch?v=J6T2bIAIxuM I did test this map on DS hardware and had no issues there either...Maybe it's something with the level you tried it on or the format of the PNG file you are trying to import that is causing problems. This wasn't done with a material settings either. The road textures them selves had partial transparency. ____________________
I have cameras in your head! |
| (post in restricted forum) |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 37/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
Posted by Fiachra Sorry about being late on replying to this. Had been caught up in other projects so hadn't had a chance to do anything SM64DS related. Sure I'll give that a try. I do know that the Collada format has changed in newer versions of Max as I recall only getting Collada files from Max 7 to work. But it's been awhile. I'll take a look. ____________________
I have cameras in your head! |
| Apache Thunder |
| ||
|
Normal user Level: 14 Posts: 38/38 EXP: 11876 Next: 1195 Since: 03-23-14 Last post: 2485 days ago Last view: 1163 days ago |
A little more separation between the D and S the DS part of the logo on option 2 would make that part more readable. Option 2 definitely looks better. ____________________
I have cameras in your head! |
| Main - Posts by Apache Thunder |
|
Page rendered in 0.044 seconds. (2048KB of memory used) MySQL - queries: 21, rows: 134/134, time: 0.033 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |
![[image]](http://i.imgur.com/vVahh6j.jpg)
![[image]](http://i.imgur.com/XBp49JA.jpg)