Register - Login
Views: 95435342
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies
10-18-18 11:41:00 AM

Jul - SM64 Hacking (Archive) - Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) New poll - New thread - Thread closed
Pages: 1 2 3 4 5 6 7 8 9 10 ... 19 20 21 22 23 24 25 26 27 28Next newer thread | Next older thread
Polygon model importer, how soon do you want it?
Please vote or be transformed into Walluigi!
Now! Even if it means it will be buggy and limited to a single untextured model!
 
11.4%, 14 votes
I could wait a month for more features and textured model import.
 
22.8%, 28 votes
I want all the features you can cram in, even if it means waiting indefinitely!
 
56.9%, 70 votes
You shouldn't have announced anything and released it when ready!
 
4.1%, 5 votes
Me don't care!
 
4.9%, 6 votes
Multi-voting is disabled. 123 users have voted.

VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 208/621
EXP: 990973
For next: 22965

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 4 days

Posted on 07-15-08 12:13:47 AM (last edited by VL-Tone at 06-14-11 05:49 PM) Link

(Update 2011-06-14: Toad's Tool 64 development is on hiatus for an indefinite amount of time.)



Hello fellow SM64 hackers!

About a month ago I sat down and decided to work on TT64 a little more, during a week-end.

A long requested feature (and an obvious one) has been the ability to import new 3d models from a file. I resisted, explaining how complicated it would be to implement. Keep in mind that my main objection was that dealing with replacement of existing models, because it would be complicated to make room for bigger models in a single bank, as moving polygon data around requires repointing every jumping commands and offsets. Another problem would be to try to translate every 3d objects parameters produced by 3d programs into SM64 polygon commands.

But then I made Flatworld Battlefield, a simple level template where it's easy to keep track of everything added. It certainly makes a difference, Messian was inspired to his wonderful polygon experiments because of the flexibility provided by this level.

Another thing is that I decided not to try to make a perfect 3d importer that can translate every features of 3d files, but instead starting with a simple one untextured model importer.

Don't ask me for 3DS support, I won't provide it, ever. I choose a more open text-based format, Wavefront .OBJ. Some of you may know about this format, it's supported by the majority of 3d programs, it's often used as a way to move 3d objects between different programs.

So, after a long weekend (and a few hours trying to squash a very stupid bug), I managed to implement a working .obj importer!





For now it only does one thing: it replaces the flat square geometry in Flatworld with the imported .obj model, and only uses the grass texture from BBB for the whole level geometry (the grass texture was modified in the levels seen in the screenshots).

I could release a new version of TT64 with this simple import feature in under a week.

But, I think people may feel too limited with this, and I don't want to deal with endless bug reports about this one because I intend to make it much better, and these changes may alter the importer enough to make the bug reports irrelevant. Anyway that's why I'm asking, if the majority wants it now, I'll release it, as is.

What I was really planning though is to have these features added before a release (and call it TT64 6.0):
-An actual interface for the importer (with a preview and parameters).
-Multiple objects import, though I'm not sure if they would be imported as individual, moveable objects, or simply added to the level geometry.
-Importing textures right from the model (using the complement .mtl file that points to texture files)
-Allow the user to set some parameters for each imported model.

This could take me a month or two... (actually it would only take me a few full days of programming, but as you may know, I don't get much free time, though it's getting better)

As for the last option, having a full featured totally perfect 3d model importer, it could take more than 6 months or never happen.

One last thing, I know I have a tendency to "disappear" without too much warning, so I could understand if some of you would've like it better if I've waited until an actual release to announce anything.

At the same time, I was sitting on this, and wanted to share it with you guys, it's pretty exciting when you realize that you could build anything (within the polygon count limitations) with a 3d program and use it as a level in SM64.

I think you can trust me on releasing the 3d importer feature within a reasonable time (this also depends on the poll result), I have more time now, and this feature is motivating.

I guess (hope) it's better than having no news from me!
Deleted User
Original user deleted
Level: NaN


Posts: 2607/-8234
EXP: NaN
For next: 0

Since: 07-26-07


Since last post: 11.0 years
Last activity: 8.0 years

Posted on 07-15-08 12:50:40 AM Link
Well you might as well release what you have now, then keep working on it. That way you'll satisfy the people who really want it now and those who want to wait for some more complex functionality can just not download it or something.
Lyskar
12210
-The Chaos within trumps the Chaos without-
Level: 185


Posts: 1581/12211
EXP: 86666121
For next: 1093614

Since: 07-03-07

From: 52-2-88-7

Since last post: 3.0 years
Last activity: 3.0 years

Posted on 07-15-08 02:41:40 AM Link
Take your time, IMO. The more time you have, the less likely the impatient people who would want it now would get it and then wind up doing more complaining about it than using it.
Deleted User
Original user deleted
Level: NaN


Posts: 18/-8234
EXP: NaN
For next: 0

Since: 07-26-07


Since last post: 11.0 years
Last activity: 8.0 years

Posted on 07-15-08 07:26:16 AM Link
Originally posted by NightKev
Well you might as well release what you have now, then keep working on it. That way you'll satisfy the people who really want it now and those who want to wait for some more complex functionality can just not download it or something.

I reckon this is the way to go. BTW VL-Tone, it is fantastic that you got model importation working!
zelda rocks

Level: 11


Posts: 7/18
EXP: 4885
For next: 1100

Since: 08-05-07


Since last post: 9.0 years
Last activity: 8.0 years

Posted on 07-15-08 07:38:24 AM (last edited by zelda rocks at 07-15-08 07:43 AM) Link
I remember that the Zelda64 model extractor uses the .OBJ format, this means you could potentially import ocarina of time into mario 64!!!

Also, you could make the .obj file from scratch, meaning you could potentially modify the levels to your hearts content, right?
messiaen
Catgirl
Level: 65


Posts: 168/1085
EXP: 2256065
For next: 79563

Since: 11-20-07


Since last post: 4.0 years
Last activity: 3.0 years

Posted on 07-15-08 11:45:01 AM Link
I would say take your time to implement things correctly, as these are crucial decisions to the future of TT64. I'm curious about the output generated by the importer, how is the generated data organized? How can much can be done about textures with manual editing? Also, could you explain more this:

"- Multiple objects import, though I'm not sure if they would be imported as individual, moveable objects, or simply added to the level geometry."

What do you mean by "movable objects" ? If you are thinking of a modular approach with new objects/behaviors like I've been experimenting with, I really wouldn't recommend it. The game can't handle it properly when you try to insert more complex models, which leads to slowdown and sometimes unpredictable bugs. But if you are thinking something like a "internal" TT64 format which will be then translated to the final polygon/collision data, then this could lead to more flexibility.

Regardings the interface for the importer, perhaps in the future you could couple it with a "bank selector", as you already have all objects/banks sorted in the SM64GeoLayoutPtrs.txt file. Something like a "Create New Level" feature, in which you select the level to replace and start with just the shared banks loaded.

Keep us updated on your progress and problems/questions you may be facing!
rstewart215804
User
Crazed Mario 64 Hacker!!!
Level: 11


Posts: 12/18
EXP: 4862
For next: 1123

Since: 09-12-07


Since last post: 9.0 years
Last activity: 8.0 years

Posted on 07-15-08 04:01:10 PM Link
Wavefront obj files. Nice choice. I myself use them for collision. The file format is quite similar to that of SM64 collision geometry. Lets see I had some code somewhere to load it into Director. A yes here it is…



------------------------------------------
global ifile --the inport file
global efile --the export file
global vb --the vertex buffer
global mb --the mesh buffer
global sb --the special buffer
global st --the selected terrain
global sp --special proptery on
------------------------------------------
on StartUp()
ifile = 0
efile = 0
vb = []
mb = []
OpenFile()
end

on CleanUp()
member("textbox 1").text = ""
end

on stopmovie
if baGetPointer(ifile) <> -1 then
baCloseFile(ifile)
end if
if baGetPointer(efile) <> -1 then
baCloseFile(efile)
end if
CleanUp()
end

on OpenFile()
set wf = new(xtra "fileio")
set objfile = displayOpen( wf )
set wf = 0
member("world").resetworld()
ifile = baGetFile(objfile, "r")
member("inport fn").text = objfile

ImportWavefront()
end

on SaveFile()
set wf = new(xtra "fileio")
set objfile = displaySave( wf )
set wf = 0
efile = baGetFile(objfile, "w")
member("export fn").text = objfile
end

on Export()
writeoffset = integer(member("").text)
baMovePointer(efile,writeoffset, "start")
baWriteUShort(efile, 64)
baWriteUShort(efile, vb.count())
repeat with v = 1 to vb.count()
baWriteShort(efile, (vb[v].x) )
baWriteShort(efile, (vb[v].y) )
baWriteShort(efile, (vb[v].x) )
end repeat
repeat with m = 1 to mb.count()
fb = member("world").ModelResource
baWriteUShort(efile, mb[m])
baWriteUShort(efile, fb[m].face.count )
repeat with f = 1 to fb[m].face.count
baWriteUShort(efile, (fb.face[f].vertices[1] - 1) )
baWriteUShort(efile, (fb.face[f].vertices[2] - 1) )
baWriteUShort(efile, (fb.face[f].vertices[3] - 1) )
if CTT(mb[m]) = true then
baWriteUShort(efile, sb[m][f] )
end if
end repeat
end repeat
end
------------------------------------------------
--------------------Editing--------------------
------------------------------------------------
on SelectObj(idn)
st = idn
end

on SelectType(tpe)
setat mb,st,tpe
if CTT(tpe) = true then
sp = true
end if
end
------------------------------------------------
--------------------Utilites--------------------
------------------------------------------------
on CTT(mn)
case mn of
14:return true --water
36:return true --sand
37:return true --sand
39:return true
44:return true --wind
45:return true
otherwise:
return false
end case
end

on Update()
if sp = true then
--show parameters
end if
end
------------------------------------------------
---------------Wavefront Section----------------
------------------------------------------------
on ImportWavefront()
vb = []
fb = []
cobj = false
cmdc = " "
repeat while cmdc <> ""
cmdc = baReadText(ifile, 1)
case cmdc of
"v":--vertex----------------------
ln = baReadLine(ifile)
xpos = float(ln.word[1])
ypos = float(ln.word[2])
zpos = float(ln.word[3])
vb.append(vector(xpos,ypos,zpos))
"f":--faces-----------------------
ln = baReadLine(ifile)
v1 = 0
v2 = 0
v3 = 0
if offset("/",ln.word[1]) = 0 then
v1 = integer(ln.word[1])
else
v1 = integer(ln.word[1].char[1 .. offset("/",ln.word[1])])
end if
------------------------------------
if offset("/",ln.word[2]) = 0 then
v2 = integer(ln.word[2])
else
v2 = integer(ln.word[2].char[1 .. offset("/",ln.word[2])])
end if
------------------------------------
if offset("/",ln.word[3]) = 0 then
v3 = integer(ln.word[3])
else
v3 = integer(ln.word[3].char[1 .. offset("/",ln.word[3])])
end if
-------------------------------------
fb.append([v1,v2,v3])
"g":--name and end of obj---------
objn = baReadLine(ifile)
if cobj = true then
CreateWFObj(fb)
fb = []
end if
if objn.char.count > 2 then
cobj = true
member("textbox 1").text = member("textbox 1").text & "Terrain" & objn & RETURN
else
cobj = false
end if
--------------------------------
(numtochar(10)):
(numtochar(13)):
otherwise:--all other junk--
baReadLine(ifile)
end case
end repeat
--------------------------------------
baCloseFile(ifile)
--------------------------------------
end

on CreateWFObj(fb)
nvs = vb.count()
nfs = fb.count()
nm = member("world").newMesh("Mesh" && string(_system.milliseconds), nfs, nvs)
nm.vertexList = vb
repeat with f = 1 to nfs
nm.face[f].vertices = fb[f]
end repeat
nm.generateNormals(#flat)
nm.build()
member("world").newModel("Mesh" && string(_system.milliseconds), nm)
end
------------------------------------------------



Its works somewhat but I will fix it later. Anyways, great job on it so far. If you need any help VL-Tone, just PM me. Have Director 11 as well and would be happy to try ease the workload.
Mega Mario XD
80
Level: 21


Posts: 81/81
EXP: 46165
For next: 3778

Since: 10-26-07

From: Australia

Since last post: 10.0 years
Last activity: 10.0 years

Posted on 07-15-08 06:24:59 PM Link
This is awesome. Keep up the good work.
AlexAR
Member
Level: 37


Posts: 49/306
EXP: 337500
For next: 753

Since: 11-30-07


Since last post: 5.0 years
Last activity: 5.0 years

Posted on 07-15-08 09:46:32 PM Link
This is beyond extraordinary VL-Tone, truly. I have so many questions about this, but it's probably better if I just keep my ignorant mouth shut. But, I have to ask one thing. Did you make those 3d models, simply "import" them into the game via whatever method, and those models "worked" perfectly? As in, did you have to worry about adding collision to em.

I see in your screenshot, Mario is clearly standing on it. Do slopes act like slopes? Steep walls act like walls? If I designed a simple small 3d landscape with a hill, square box and floating platform, would it all act right without me having to explicitly tell the game how Mario should interact with each land feature?
Boing
450
Level: 45


Posts: 73/458
EXP: 616715
For next: 43449

Since: 12-16-07

From: Michigan, US

Since last post: 7.0 years
Last activity: 7.0 years

Posted on 07-16-08 12:06:40 AM Link
I would personally much rather see a built-in geometry editor, but hey, beggars can't be choosers. I think you should keep adding features and release it once it is a bit more complete.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 209/621
EXP: 990973
For next: 22965

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 4 days

Posted on 07-16-08 12:15:49 AM (last edited by VL-Tone at 07-16-08 12:26 AM) Link
Ok there seems to be some divergence of opinions in the poll, as nobody voted (yet) for the second choice. So I guess that ironically I'll do something in between the first and third choice, that is: not releasing the barebones importer now, but not waiting indefinitely either until I get a perfect importer with every features possible. Also I guess I'll have to lean more on the third choice since it got more votes.



Originally posted by zelda rocks
I remember that the Zelda64 model extractor uses the .OBJ format, this means you could potentially import ocarina of time into mario 64!!!

Also, you could make the .obj file from scratch, meaning you could potentially modify the levels to your hearts content, right?


You can only make the .obj file from scratch using a 3d program, you can't use models already in the game, and for reasons I mentioned before you won't be able to modify the existing levels, only Flatworld.


Originally posted by messiaen
I would say take your time to implement things correctly, as these are crucial decisions to the future of TT64. I'm curious about the output generated by the importer, how is the generated data organized? How can much can be done about textures with manual editing? Also, could you explain more this:

"- Multiple objects import, though I'm not sure if they would be imported as individual, moveable objects, or simply added to the level geometry."

What do you mean by "movable objects" ? If you are thinking of a modular approach with new objects/behaviors like I've been experimenting with, I really wouldn't recommend it. The game can't handle it properly when you try to insert more complex models, which leads to slowdown and sometimes unpredictable bugs. But if you are thinking something like a "internal" TT64 format which will be then translated to the final polygon/collision data, then this could lead to more flexibility.

Regardings the interface for the importer, perhaps in the future you could couple it with a "bank selector", as you already have all objects/banks sorted in the SM64GeoLayoutPtrs.txt file. Something like a "Create New Level" feature, in which you select the level to replace and start with just the shared banks loaded.

Keep us updated on your progress and problems/questions you may be facing!



When I talk about movable objects, I am indeed talking about independent objects like the platforms you created. I guess the problems with having a lot of these is the multiple collision behaviors that mainly slow down the game, I think you're right that merging the collision polygons for moveable platforms with the main platform would be a better approach. I know you're interested in a feature where the main collision polygons could be generated for a level using polygons from each movable platform, but to make something like that user friendly wouldn't be that simple (just an example of a potential problem, how do you determine which object needs to have their collision generated?). In any case, there is still a need for independent objects that have their own collision data: anything moving, rotating, tilting... Importing models as usable 0x24 objects could also be useful to create new enemies or characters...

For now, I'll focus on importation of the main level geometry, with the possibility of splitting the model in groups that are put in the level using 0x15 geometry layout commands. Importation of individual objects will come later.

As for a bank selector, I'm also planning it, as well as the possibility of having multiple "Flatworld" levels.

Originally posted by rstewart215804
Wavefront obj files. Nice choice. I myself use them for collision. The file format is quite similar to that of SM64 collision geometry. Lets see I had some code somewhere to load it into Director. A yes here it is…



Code snippet...



Its works somewhat but I will fix it later. Anyways, great job on it so far. If you need any help VL-Tone, just PM me. Have Director 11 as well and would be happy to try ease the workload.



Thanks for the code! I may not use it as such but maybe I could take a look at the export code if I ever come around to implement such a feature.

BTW your importing code is not that different from mine, except for the missing normals and texture coordinates importation, and the fact that my importer can also deal with faces that have 4 vertices (some 3d programs will generate faces with either 3 or 4 vertices per face)

Here's a little tip for dealing with the "/" separating without resorting to using the "offset command".


_player.itemDelimiter="/"


Using this command, you'll be able to refer to vertices numbers in faces commands as items.

(("f 5/6/7/8").word[2]).item[3] would return "7". (The parenthesis around "("f 5/6/7/8").word[2]" are important)

Don't forget to set the item delimiter back to "," when your routine is finished.

I didn't have any major problems coding the .obj importer itself. The "hard" part was translating the imported vertices, triangles, normals and texture coordinates into a n64 GBI commands display list. I had to build some code to deal with the texture cache limitation (though the result is barely optimized). It wasn't "that hard", but it took me much more time coding that part than simply importing the .obj data into variables.

As for needing your help, I don't think I'll give you my source file, as you would probably find it messy and hard to understand TT64 would need yet another rewrite, but I don't feel like it at this point. Still, I'll try to see what I could ask you, for example maybe I could ask you to make a routine that creates and merge collision data from multiple independent objets (for the feature that messian is asking for). Not that I can't do it myself, but it could save me some work and stress.

Originally posted by AlexAR
This is beyond extraordinary VL-Tone, truly. I have so many questions about this, but it's probably better if I just keep my ignorant mouth shut. But, I have to ask one thing. Did you make those 3d models, simply "import" them into the game via whatever method, and those models "worked" perfectly? As in, did you have to worry about adding collision to em.

I see in your screenshot, Mario is clearly standing on it. Do slopes act like slopes? Steep walls act like walls? If I designed a simple small 3d landscape with a hill, square box and floating platform, would it all act right without me having to explicitly tell the game how Mario should interact with each land feature?


I created these models using a simple 3d program (Cheetah 3d on the Mac) but I could've used Maya, and you could also use 3DStudio Max or Blender, amongst many others. I used simple geometric figures, a sphere, a torus and generated a height terrain, mainly for testing purposes. You can make something much more complicated than this with your favorite 3d program, keeping in mind that the n64 has a limited amount of memory, and too many polygons would generate to much data and crash the game upon loading the level.

The collision data was automatically generated along with the polygon data by TT64 while importing, along with a "death floor" at the bottom of the level (you don't have to create it yourself). In the screenshots, I set the type of terrain to "ultra non slippery" as used in the very steep slanted platform in the third Bowser course.

My intended goal was to make a small "Super Mario Galaxy"-like level. Mario can walk around the sides of the sphere almost in a vertical way, but unfortunately he'll still fall if he gets really close to the side, even with this type of terrain he can't walk on a perfectly vertical wall, and even less under the sphere.

I'm thinking of allowing the user to set different parameters to each model groups found in an .obj file, collision type would be one of them.

As far as walking on the top of the sphere, the effect is close to SMG, except when Mario stops walking, he'll stand vertically, unlike SMG where Mario will remain perpendicular to the ground. While there may be a way to make Mario remain perpendicular when standing still, there's no way that a simple hack will enable Mario to walk all around a sphere like in SMG. The gravity in SM64 has only one direction, while in SMG gravity can pull Mario from many different directions, Nintendo had to build a special gravity engine for SMG. Not only it would be really hard to program into SM64, but I doubt that the N64 processor could handle it.

Originally posted by Boing
I would personally much rather see a built-in geometry editor, but hey, beggars can't be choosers. I think you should keep adding features and release it once it is a bit more complete.


Do you know of any 3d game level editors that feature built-in geometry editors? As far as I know, most rely on importation of external objects created with a dedicated 3d program. Mario 64 models themselves were created using an external 3d editor (Nichimen N-World, which I can't find anywhere to download unfortunately).
Deleted User
Original user deleted
Level: NaN


Posts: 19/-8234
EXP: NaN
For next: 0

Since: 07-26-07


Since last post: 11.0 years
Last activity: 8.0 years

Posted on 07-16-08 05:21:07 AM Link
I have a question VL-Tone. Will the version of Toad's Tool 64 with model importation support hardware accelaration on Vista?
Plareon
User
Level: 12


Posts: 24/24
EXP: 7471
For next: 450

Since: 09-28-07

From: North America

Since last post: 10.0 years
Last activity: 10.0 years

Posted on 07-16-08 09:28:41 AM (last edited by Plareon at 07-16-08 09:40 AM) Link
I... I... I am speechless.





VL-Tone! You have probably reached the limit of hacking so high that Nintendo didn't even consider when they made Mario 64 for ANYONE to be able to do this! If Nintendo sees this, or if they already saw it, they'll be like, "Twelve years ago we made a great game. We thought it was impossible to go this far. We were wrong..."


You rock!

(I guess I wasn't THAT speechless after all...)
RomanianGirl

Level: 16


Posts: 13/42
EXP: 17026
For next: 3230

Since: 01-31-08

From: Canada

Since last post: 9.0 years
Last activity: 9.0 years

Posted on 07-17-08 07:59:17 PM Link
This is very awesome! A part of me wants this immediately, but it is definitely better if you took the time to make sure everything is alright. Great job!

Do 3D programs offer the option to save as .obj? I have worked with Maya before, but I didn't explore the save options. I apologize if this question is useless, but I would like to know. Thank you!
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 211/621
EXP: 990973
For next: 22965

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 4 days

Posted on 07-17-08 11:44:50 PM (last edited by VL-Tone at 07-17-08 11:48 PM) Link
Originally posted by Blaster
I have a question VL-Tone. Will the version of Toad's Tool 64 with model importation support hardware accelaration on Vista?


Yes it will, though I may release separate versions for XP, Vista, PPC and intel Macs.

Originally posted by RomanianGirl
Do 3D programs offer the option to save as .obj? I have worked with Maya before, but I didn't explore the save options. I apologize if this question is useless, but I would like to know. Thank you!


I'd say that the vast majority of 3d programs support .obj exporting, most have it built-in, some require a plug-in. Maya includes a plug-in, but you have to enable/load it to get full functionality by checking some checkbox.
messiaen
Catgirl
Level: 65


Posts: 175/1085
EXP: 2256065
For next: 79563

Since: 11-20-07


Since last post: 4.0 years
Last activity: 3.0 years

Posted on 07-19-08 01:06:01 PM (last edited by messiaen at 07-19-08 01:06 PM) Link
I have a suggestion to make the level terrain/collision data a bit more modular, so that TT64 could handle level meshes (object groups in the original .obj file) in its interface.

The 0x15 call display list command already can give a modular aspect to each object group in the .obj file. What about if you separated each object group in the main 0x40 collision vertex list by a fake (pseudo) vertice? Or even two, one at the beggining and one at the end of each object.

These fake vertices could contain pointers to the respective 0x15 Geo Layout command and also to the respective triangle group in the collision data (I'm supposing each object has its own triangle command). With this data, it would be easier to make TT64 move/rotate/scale/delete object groups.

If this doesn't sounds good, then ignore it, it's just a idea I had earlier on .
Raccoon Sam
Member
free speech disabled
Level: 30


Posts: 65/187
EXP: 163800
For next: 2069

Since: 07-25-07

From: Somewhat

Since last post: 339 days
Last activity: 42 days

Posted on 07-19-08 07:12:15 PM Link
OBJ? Awright! To me, 3DS is nothing more than triangulation issues.

Anyone who wants to try their best with 3D modeling, below are some Free 3D modelers that support exporting to OBJ.
-Metasequoia
-Blender
-Sketchup
Stevoisiak
Member
Level: 36


Posts: 98/283
EXP: 300443
For next: 7667

Since: 11-22-07

From: New York, Long Island

Since last post: 8.0 years
Last activity: 2.0 years

Posted on 07-20-08 04:55:10 PM Link
I say for now just release a small seperate app for the importer. (Like you did with the text editor)
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 212/621
EXP: 990973
For next: 22965

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 4 days

Posted on 07-20-08 09:09:43 PM Link
Originally posted by messiaen
I have a suggestion to make the level terrain/collision data a bit more modular, so that TT64 could handle level meshes (object groups in the original .obj file) in its interface.

The 0x15 call display list command already can give a modular aspect to each object group in the .obj file. What about if you separated each object group in the main 0x40 collision vertex list by a fake (pseudo) vertice? Or even two, one at the beggining and one at the end of each object.

These fake vertices could contain pointers to the respective 0x15 Geo Layout command and also to the respective triangle group in the collision data (I'm supposing each object has its own triangle command). With this data, it would be easier to make TT64 move/rotate/scale/delete object groups.

If this doesn't sounds good, then ignore it, it's just a idea I had earlier on .



I understand what you're getting at, though I'm not sure it would be the best way to do it. Anyway, I think that it would require too much programming for something that you could do from inside your favorite 3d program. Remember that with a 3d program, you can move/rotate/scale/delete each of theses groups anyway...

Originally posted by Stevoisiak
I say for now just release a small seperate app for the importer. (Like you did with the text editor)


That's a good idea, I didn't think about that... The problem is that the current version of TT64 is dependent on the already generated m64geometry file to draw polygons. To load modified polygons you need to delete that file so it will be re-generated when opening the ROM, and you'd have to do that each time you re-import your .obj file.

My current development version (which will be version 6.0) decode polygon in RAM gradually as needed and can reload specific models when requested, such as when you import a new level geometry.
Stevoisiak
Member
Level: 36


Posts: 99/283
EXP: 300443
For next: 7667

Since: 11-22-07

From: New York, Long Island

Since last post: 8.0 years
Last activity: 2.0 years

Posted on 07-21-08 10:49:43 AM Link
Originally posted by VL-Tone
Originally posted by Stevoisiak
I say for now just release a small seperate app for the importer. (Like you did with the text editor)


That's a good idea, I didn't think about that... The problem is that the current version of TT64 is dependent on the already generated m64geometry file to draw polygons. To load modified polygons you need to delete that file so it will be re-generated when opening the ROM, and you'd have to do that each time you re-import your .obj file.

My current development version (which will be version 6.0) decode polygon in RAM gradually as needed and can reload specific models when requested, such as when you import a new level geometry.



Yeah, I was thinking that would be a good idea. For now though, maybe TT can just check if there are any model errors and if so, regenerate the file. Or just have a question on startup asking to remake it.
Pages: 1 2 3 4 5 6 7 8 9 10 ... 19 20 21 22 23 24 25 26 27 28Next newer thread | Next older thread
Jul - SM64 Hacking (Archive) - Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) New poll - New thread - Thread closed




Rusted Logic

Acmlmboard - commit 5d36857 [2018-03-03]
©2000-2018 Acmlm, Xkeeper, Inuyasha, et al.

41 database queries, 5 query cache hits.
Query execution time: 0.206974 seconds
Script execution time: 0.042118 seconds
Total render time: 0.249092 seconds
Memory used: 786432