Kuribo64
Views: 19,853,282 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
03-29-24 01:11 AM
Guest:

0 users reading Editor development | 2 bots

Main - General SM64DS hacking - Editor development Hide post layouts | New reply

Pages: 1 2 3 4 5 ... 15 16 17 18 19 20 21 22 23 ... 27 28 29 30 31
Apache Thunder
Posted on 03-31-14 07:21 AM (rev. 4 of 03-31-14 07:25 AM) Link | #39743
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. :D

Perhaps a longer term goal is to merge/display the KCL model and the visible model in the same viewport. ;)

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

Fiachra
Posted on 03-31-14 08:00 PM Link | #39753
Posted by Apache Thunder
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)? ... 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.

It would make it too cluttered, I wouldn't want to limit it to only the types available in the level when importing so you'd have to have a drop-down menu and an option to enter any value.
The known types are already stored and are used in the 'CLPS' editor to allow to view and set the collision types available in a level.
Very few of the collision types are documented and there actually are hundreds of them, there's no set list of available types, different bytes have different meanings, eg. in some levels one of the bytes is a path ID. So it's not really feasible to make a comprehensive database (also all the different bytes' meaning aren't known).
Also the ability to select/highlight faces by material. That way I can easily tell which faces the selected material is assigned to. ...
It's assumed you know what materials are used where, your 3D modelling program should allow you to do this (I know it's very easy in Blender).
It should be possible to select all the faces with the same image and assign them to the one material before exporting (you may need to join the two objects into one mesh).
I do intend to add the ability to click on single and multiple faces in the KCL editor to assign them types that way though.

Perhaps a longer term goal is to merge/display the KCL model and the visible model in the same viewport. ;)

The KCL editor should be kept separate, merging its functionality with the level editor would make it too messy, eg. how would you handle opening any KCL in the game, assigning per face etc.
The code's already there for simply overlaying the collision map over the level model (Mega-Mario had it in for testing), it's just commented out. I might make this an option you can toggle on and off.

Apache Thunder
Posted on 04-02-14 04:36 AM (rev. 3 of 04-02-14 04:42 AM) Link | #39804
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. :P

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

Cackletta
(post deleted) #39820

Fiachra
Posted on 04-03-14 06:58 PM Link | #39830
I've added a wireframe overlay to the KCL in the KCL Editor, it also seems that the 'Fill' mode wasn't working properly:

[image]

"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." - I don't understand what you mean here. Within the KCL editor at the minute the only model visible is the KCL mesh.

I'm working on selecting faces by clicking. Both changes should hopefully be in the next revision.

Apache Thunder
Posted on 04-04-14 11:34 PM (rev. 8 of 04-04-14 11:46 PM) Link | #39857
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. :D

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.

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

Fiachra
Posted on 04-05-14 06:50 PM Link | #39868
"... Meshes will always import with all the materials set to collision type 0, (so all the materials will have the same color) ..." - When importing you can enter the value for the collision type for each material and click 'Assign Types' before clicking on 'Import'.

The reason you lose the shading is becuase OBJ doesn't support vertex colours, there is a Blender-specific "Extended OBJ" plugin that allows importing and exporting non-standard OBJ models with vertex colours. I believe blank's BDL importer for SMG games supports this and I'll probably add support as well.

"... DAE export ability would be a definite long term goal ..." - It already is a long term goal. Eventually I would like to have the following with regards to DAE, in order of priority:
- Importing models with proper DAE bones systems with per-vertex bone assignments (vertex weighting but BMD only lets assign vertices to a bone, not weight them), to replace the .bones file for DAE.
- Importing animation from DAE files, using the bones defined in the model ie. completely and perfectly import new animation and characters.
- Exporting static models as DAE.
- Exporting above so that existing models and animations can be edited (much lower priority, can do without).

Note that these could take a while as I know hardly anything about 3D animation or how DAE's implementation.

Apache Thunder
Posted on 04-05-14 11:30 PM (rev. 2 of 04-06-14 04:11 AM) Link | #39893
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.

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

skawo
Posted on 04-06-14 08:04 AM Link | #39914
Mm, that could be neat ^, if I recall the Banjo-Kazooie editor did something like that. Could steal look at how they did that there.

Fiachra
Posted on 04-06-14 12:13 PM Link | #39918
There's no need - it's already possible to import vertex colours through DAE models.

I mentioned import support for "Extended OBJ" simply to make it possible to re-import exported OBJ models using the non-standard vertex colours. If you want vertex colours you should export your model as DAE from within your 3D editor and then import that.

This is supposed to be a model importer, I don't want to start duplicating functionality from 3D editors when it's not necessary. Vertex colours can be viewed fine in a 3D editor before exporting. Also, how would you then save the vertex colours you added if you wanted to re-import that model? You end up with re-exporting and importing anyway.

"On that note, don't forget to add partial transparency to any faces using the water collision type." - I'm not going to force transparency on users for certain collision types, the user should be deciding the transparency etc. of the model.

skawo
Posted on 04-06-14 01:16 PM Link | #39919
There's no need - it's already possible to import vertex colours through DAE models.


Yeah, but if it makes something much easier to achieve (and it does, since you wouldn't have to futz about with 584930 different editors and exporters), it should be considered.

Apache Thunder
Posted on 04-06-14 04:07 PM (rev. 3 of 04-06-14 04:08 PM) Link | #39921
Posted by Fiachra
I'm not going to force transparency on users for certain collision types, the user should be deciding the transparency etc. of the model.


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

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

Fiachra
Posted on 04-07-14 04:03 PM Link | #39961
Posted by skawo
Yeah, but if it makes something much easier to achieve (and it does, since you wouldn't have to futz about with 584930 different editors and exporters), it should be considered.

You can import models with vertex colours by importing DAE models, there's no need to make it more complex, just export your model as DAE - surely that is simpler than exporting as OBJ, adding vertex colours in the Model Importer window, importing that into the game and then somehow exporting your edited model to a format that supports vertex colours which you'd then have to import back into your 3D editor.

Posted by Apache Thunder
I'm talking about alpha in the KCL viewer
OK, I thought you meant when importing models as you said "on that note" just after the DAE features post.
It wouldn't really be possible to only translucency have for faces using a water collision type but I'll add some sort of translucency option to make viewing all faces easier, probably a "Translucent Mode" that makes everything translucent.

skawo
Posted on 04-07-14 04:08 PM Link | #39962
Posted by Fiachra
surely that is simpler than exporting as OBJ, adding vertex colours in the Model Importer window, importing that into the game and then somehow exporting your edited model to a format that supports vertex colours which you'd then have to import back into your 3D editor.


That's not even what was proposed.

Fiachra
Posted on 04-07-14 04:24 PM (rev. 2 of 04-07-14 04:26 PM) Link | #39963
Posted by skawo
That's not even what was proposed.


What was proposed was allowing vertex colours to be edited when importing a model.

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.


I'm saying that in order to be able to save the changes to the model to edit later etc. you would need to be able to export the edited model from the game with the vertex colours that were added intact (requires exporting to DAE) and that it would be simpler to simply edit the vertex colours in the 3D editor first and then export to DAE and import the DAE model into the game. Vertex colouring is something that I think should be left to the 3D editor.

Cackletta
Posted on 04-07-14 08:39 PM Link | #39973
When exporting OBJ there is an harmless blank file created name "vtx" acronym of vertex BTW, could that ever be of any use because OBJ files are too basic for that, although I open it in a hex editor and saw 4 vertices of RGB values following each other, this was a ripped sonic heroes stage converted to OBJ. That RGB seemed to be for the water because when I read the RGBS the was blue y'know, hexadecimal converted to hex and then RGB values paste into a paint utility that will interpret the color.

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

Apache Thunder
Posted on 04-07-14 08:45 PM (rev. 4 of 04-07-14 09:01 PM) Link | #39978
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? :P )

EDIT: Ok here's screenshot:

[image]

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]

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

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

BlackYoshi485
Posted on 04-07-14 09:50 PM Link | #39986
I think what would be better an tool for adding vertex colors in the SM64DSe model import.

Like an OPEN MODEL- IMPORT- and an window with the message: " This model didn't have vertex colors, ¿Did you want to add vertex colors to your model?

I didn't think if is posible. :P

Jesse
Posted on 04-08-14 12:41 PM Link | #39995
well the banjo kazooie level importer had that...

Fiachra
Posted on 04-08-14 06:18 PM Link | #39996

Posted by Apache Thunder
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? :P )

EDIT: Ok here's screenshot:


[image]

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]

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

Vertex colours are working for me.

In DAE, plain vertex colours are stored in a float array of R G B values within a <source> tag and referenced by an <input semantic="COLOR" ... /> tag within a <triangles>, <polylist> or <polygons> element (for polygons).

I suspect that 3DS Max is either using some additional data for storing/calculating vertex colours and isn't "baking" these into the mesh as above when exporting or that it isn't vertex colours, but something else being edited in that 2nd screenshot. I'm not familiar with 3DS Max, the features (Radiosity etc.) you mentioned or have access to it - can you send me your castle model from the screenshots so I can have a look at them? If possible can you send me a less complex model with the same problem (easier to work with).

BlackYoshi485 and jjesss064: I've already gone over this, see above posts.
Pages: 1 2 3 4 5 ... 15 16 17 18 19 20 21 22 23 ... 27 28 29 30 31

Main - General SM64DS hacking - Editor development Hide post layouts | New reply

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