Kuribo64
Views: 11,112,083 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
08-15-20 03:39 PM
Guest:

0 users reading Editor development | 1 bot

Main - General SM64DS hacking - Editor development New reply

Pages: 1 2 3 4 5 ... 16 17 18 19 20 21 22 23 24 ... 27 28 29 30 31
Apache Thunder
Posted on 04-08-14 07:05 PM (rev. 2 of 04-08-14 07:05 PM) Link | #39998
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. :(

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

Fiachra
Posted on 04-09-14 02:38 PM (rev. 2 of 04-09-14 02:40 PM) Link | #40019
I know what the problem is - when exporting vertex colours 3DS Max is exporting them with as ARGB values instead of RGB, meaning there are four values for each colour where the editor is expecting three (as there should be). Removing the extra alpha values allowed the model to load correctly.

Although 3DS Max is breaking the specification here, I'll update the editor to strip out the extra values when loading the model (the DS doesn't support per-vertex alpha values, otherwise I would have allowed using the alpha values).

There seems to also be something wrong with the way 3DS Max exports DAE models in general, Blender couldn't even load the models and MeshLab could only load the vertices.

Apache Thunder
Posted on 04-09-14 05:40 PM (rev. 6 of 04-10-14 01:23 PM) Link | #40025
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. :P

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. :D

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. :P ) 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. :D

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. :D

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

Fiachra
Posted on 04-10-14 01:58 PM Link | #40037
Posted by Apache Thunder
I also had to rotate the model -90 degrees ... I tried the flip Y/Z axis option on export, but it seems to have no effect ...

3DS Max is probably just changing the tag <up_axis> when exporting, which is currently ignored though is likely to be implemented soon.

Posted by Apache Thunder
Ok as for the messed up textures on my merged Castle Grounds ...

What do you mean by messed up textures? Are you referring to the fact that exported models' textures don't look the same when re-imported? If so, this is becuase the BMD model stores attributes for textures such as mirror-repeat which isn't supported in either OBJ or DAE.

Apache Thunder
Posted on 04-10-14 03:07 PM (rev. 2 of 04-10-14 03:10 PM) Link | #40038
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.

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

Fiachra
Posted on 04-10-14 04:03 PM Link | #40039
It may still be the size and amount of the textures, or glitches like that can also occur when the texture being imported isn't an 'Indexed' image. Can you try setting them to be indexed and then re-importing? If that doesn't work you can PM me the model and I'll try and get it to work.

Also, the limit is around 5000 faces for a level model, 2048 is simply the maximum amount that the hardware can show on screen at any time.

Apache Thunder
Posted on 04-10-14 04:12 PM (rev. 10 of 04-10-14 11:24 PM) Link | #40040
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. :D


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. :P

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. :D

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

skawo
Posted on 04-11-14 04:55 AM Link | #40053
Well...

1) You can move the object closer and further with the mousewheel. That should help, perhaps?

2) Ctrl+C and Ctrl+V, albeit it's incredibly finnicky, only works if selecting objects from the 3D view and not from the object list and also a bit broken because it doesn't copy the rotation and 'Star To Appear on' settings (in fact, it clears the copied object's 'Star To Appear on' setting, as well)

Fiachra
Posted on 04-11-14 02:05 PM Link | #40060
1) It might be easier if you zoom out further when placing them, it would be very hard and probably slow trying to calculate collision for setting positions.

2) (Mulitple object selection) - That was already the next planned feature to add, will also include multiple copy and paste.

3) As (2) in above post, inserting at a slight height offset is a good idea, especially when pasting multiple objects.

4) You should delete the nodes and then the path objects starting with the last ones.

5) There's currently a problem when re-importing an XML with the views, once that's fixed though you could just export the XML, remove all objects and then re-import it.

Apache Thunder
Posted on 04-11-14 02:16 PM (rev. 2 of 04-11-14 02:23 PM) Link | #40061
I had tried that. I get this error once I try to delete the last path node:


[image]



************** Exception Text **************
System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: index
at System.Linq.Enumerable.ElementAt[TSource](IEnumerable`1 source, Int32 index)
at SM64DSe.LevelEditorForm.updatePathsNodeRemoved(PathPointObject removedNode) in C:\Users\Fiachra\Documents\Visual Studio 2010\Projects\SM64DSe Mono\SM64DSe\LevelEditorForm.cs:line 2543
at SM64DSe.LevelEditorForm.btnRemoveSel_Click(Object sender, EventArgs e) in C:\Users\Fiachra\Documents\Visual Studio 2010\Projects\SM64DSe Mono\SM64DSe\LevelEditorForm.cs:line 2289
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18444 built by: FX451RTMGDR
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
SM64DSe
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Spenser/Desktop/Pinned/Games/NDS/NDSTools/SM64DSse/SM64DSe.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
OpenTK
Assembly Version: 1.0.0.0
Win32 Version: 1.0.278.44921
CodeBase: file:///C:/Users/Spenser/Desktop/Pinned/Games/NDS/NDSTools/SM64DSse/OpenTK.DLL
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
HaxxGLControl
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Spenser/Desktop/Pinned/Games/NDS/NDSTools/SM64DSse/HaxxGLControl.DLL
----------------------------------------
OpenTK.GLControl
Assembly Version: 1.0.0.0
Win32 Version: 1.0.278.44921
CodeBase: file:///C:/Users/Spenser/Desktop/Pinned/Games/NDS/NDSTools/SM64DSse/OpenTK.GLControl.DLL
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:





When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

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)

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

Fiachra
Posted on 04-11-14 04:02 PM Link | #40065
Seems it's a bug, will fix for next revision.

Apache Thunder
Posted on 04-11-14 11:57 PM (rev. 10 of 04-12-14 12:15 AM) Link | #40088
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... :P


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. :P (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. :D

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. :D

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

Fiachra
Posted on 04-12-14 06:52 AM Link | #40090
That DeSmuME version looks a lot a better. I never understood why that feature didn't already exist. Aparently the creator doesn't like it as it's not an accurate emulation.

Link to higher resolution DeSmuME:
http://forums.pcsx2.net/Thread-Unofficial-Desmume-X432R-with-option-to-increase-internal-resolution

"... It would really make them stand out. ..." - Vertex colours do make a huge difference, that's why it was added. You can see looking at the early videos of my hack there wasn't any shading, then using "shadow" materials, only the last 4 have had vertex colours. I'll be going back over them to have them all use vertex colours. Noki Bay in particular could look much, much better with vertex colours.

"The only minor issue left is the tree shadow textures." - I'm not actually sure why that particular texture doesn't work. I was able to replace it with another unindexed PNG with translucency and it worked.

Re-importing textures without alpha colours from the game without indexing them should be fine as these will have at most 256 colours. Images with more than 256 colours however the editor will try to reduce the amount of colours down to 256 and may not give the results you want. The textures used in Hyrule Field probably had 256 colours or fewer.

"... I did indeed check the transparency setting for the material in the DAE file ..." - Are you sure you're setting the transparency of the tree shadow material properly in the DAE model? There should be an element like below:
<transparency>
<float sid="transparency">1.0</float>
</transparency>

Set it to a value less than 1 for transparency. The <transparent> tag is not used.

Cackletta
Posted on 04-17-14 04:31 AM Link | #40310

[image]
Regarding what Apachethunder said, Blender isn't that limited it can handle vertex colors, the vertex color problem is from the DAE file itself, my sonic heroes stage mismatched the vertex color, I exported it with 3DS MAX but the water remains un vertex colored.

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

Fiachra
Posted on 04-17-14 02:48 PM Link | #40332
I don't quite understand what you're saying. Are you saying that models exported from 3DS Max aren't importing with proper vertex colours into SM64DSe? If so, that'll be fixed in the next revision. What are you saying about Blender's handling of vertex colours? (Blender stupidly can't import vertex colours from DAE if you're referring to that).

Apache Thunder
Posted on 04-17-14 08:55 PM (rev. 5 of 04-18-14 12:18 AM) Link | #40364
Posted by Cackletta
Regarding what Apachethunder said, Blender isn't that limited it can handle vertex colors, the vertex color problem is from the DAE file itself, my sonic heroes stage mismatched the vertex color, I exported it with 3DS MAX but the water remains un vertex colored.


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. :P) 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. :D

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

Skelux
Posted on 04-23-14 04:45 AM (rev. 2 of 04-23-14 04:47 AM) Link | #40523
Would it be possible to import vertex normals from OBJ files? I'd like to see some proper shading in my levels. I'm aware they don't work the same way as SM64, but I still don't see why you couldn't import them as a fixed form of shading.

Also, I notice you're looking into level boundaries. I removed boundaries in SM64 by multiplying Mario's coordinates by 0.25 before writing them to memory, then multiplying them by 4 when reading them. This was after weeks of failed attempts - It turned out that something so simple worked. A similar method may work for SM64DS.

Fiachra
Posted on 04-23-14 05:15 AM Link | #40525
Posted by Skelux
Would it be possible to import vertex normals from OBJ files? I'd like to see some proper shading in my levels. I'm aware they don't work the same way as SM64, but I still don't see why you couldn't import them as a fixed form of shading.

Yes, it looks like that should be possible (for both OBJ and DAE).

Also, I notice you're looking into level boundaries. I removed boundaries in SM64 by multiplying Mario's coordinates by 0.25 before writing them to memory, then multiplying them by 4 when reading them. This was after weeks of failed attempts - It turned out that something so simple worked. A similar method may work for SM64DS.

Thanks, I'll see about trying that.

Skelux
Posted on 04-23-14 01:33 PM Link | #40532
One more detail - not sure if it would be fixable, but semi-transparent textures freeze the game.

Apache Thunder
Posted on 04-23-14 05:00 PM (rev. 4 of 04-23-14 05:04 PM) Link | #40535
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.

____________________
[image][image][image]
I have cameras in your head!
Pages: 1 2 3 4 5 ... 16 17 18 19 20 21 22 23 24 ... 27 28 29 30 31

Main - General SM64DS hacking - Editor development New reply

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