|
 |
« Reply #8475 on: January 27, 2012, 02:54:11 PM » |
|
I've seen a lot of models in okami called nurbsToPoly, so I'm guessing they're not supported if the devs had to convert (v10 MDL0, mind you.)
|
|
|
Logged
|
 FC: 2191-7379-6272
|
|
|
|
|
 |
« Reply #8476 on: January 27, 2012, 03:01:09 PM » |
|
Proper rig? Right mdl0 version? Bezier curves?
|
|
|
Logged
|
|
|
|
|
|
|
 |
« Reply #8478 on: January 27, 2012, 05:26:51 PM » |
|
Hey,BJ. I'm Bero,who had programmed BBox before you started to program it. Though I developed BBox,I didn't touched model things and have a question about them. Why is it that textures of some models(menu and etc.) aren't shown properly on model previewer? Because I'd like to make a title scene on my own,I have to use your model importer. I think I should first export the model,but the previewer shows it like this: http://img571.imageshack.us/img571/5593/65831308.pngOh I know who you are, Bero.  I think it has to do with the vertices not being XYZ. I've been looking into it for a while now... It either has to do with the vertex remapping process or how the vertices are loaded into the buffer (which is what I'm thinking). I'll see if I can fix it soon. That reminds me that BrawlBox also seems to have trouble rendering models with an enormous amount of polygons in one group. Namely Trace.brres in the "toy\fig" folder, with well over 41k polygons in the polygon1 group.  And turning on the vertices shows more of the model, but even then it seems to just suddenly stop before rendering its left arm fully:  . While not super-important, it should be looked into at a later time. Yeah, that's another thing I need to look into fixing... that probably has to do with the vertex remapping or maybe it's some kind of limitation of OpenGL (which would be odd).
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8479 on: January 27, 2012, 05:43:42 PM » |
|
Oh I know who you are, Bero.  I think it has to do with the vertices not being XYZ. I've been looking into it for a while now... It either has to do with the vertex remapping process or how the vertices are loaded into the buffer (which is what I'm thinking). I'll see if I can fix it soon. Yeah, that's another thing I need to look into fixing... that probably has to do with the vertex remapping or maybe it's some kind of limitation of OpenGL (which would be odd). If it was a limitation, you should be able to find out easily by removing Trace's polygons to see if the problem ones still exist. If it sounds like a good idea to you, I'd go out of my way to quickly test that.
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8480 on: January 27, 2012, 06:44:07 PM » |
|
IDK if OGL has a limit to it's display lists... (a number of primitives you can draw)
it would be wierd if it did, but I don't think so >_>
I think if there is a limit, it'd be something with brbx
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8481 on: January 27, 2012, 06:48:18 PM » |
|
IDK if OGL has a limit to it's display lists... (a number of primitives you can draw)
it would be wierd if it did, but I don't think so >_>
I think if there is a limit, it'd be something with brbx
Maybe the graphics buffer is too big or something. All of the data, vertex positions, normal positions, both color pixels and all 8 uv positions are stored in one large buffer of data... >.>
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8482 on: January 27, 2012, 07:03:58 PM » |
|
curious...
how do you draw the seperate UV channels in the display list??
do you use GL_ARB or GLSL?? (if GLSL, how?? (PM me))
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8483 on: January 27, 2012, 11:14:44 PM » |
|
Maybe the graphics buffer is too big or something. All of the data, vertex positions, normal positions, both color pixels and all 8 uv positions are stored in one large buffer of data... >.>
0.63 displays the model fine (as fine as 0.63 model previewer was), while 0.64 doesn't. If that helps at all, that is.
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8484 on: January 27, 2012, 11:19:42 PM » |
|
0.63 displays the model fine (as fine as 0.63 model previewer was), while 0.64 doesn't. If that helps at all, that is.
lol yeah this problem popped up after Kryal updated the way facepoints were read in the source. Btw, almost have BB ready for release (actually, it technically IS ready), but I want to figure out what's up with SCN0s changing in file size after being rebuilt and figure out what's wrong with flat models.
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8485 on: January 28, 2012, 01:07:47 AM » |
|
lol yeah this problem popped up after Kryal updated the way facepoints were read in the source.
Btw, almost have BB ready for release (actually, it technically IS ready), but I want to figure out what's up with SCN0s changing in file size after being rebuilt and figure out what's wrong with flat models.
Oooh~ I'm looking forward to this release in particular, I needed to at least see some texture animation info for a bunch of models I was ripping.
|
|
« Last Edit: January 28, 2012, 01:13:04 AM by Friedslick6 »
|
Logged
|
At some point, you just have to bend down and tie your shoelaces.
|
|
|
|
|
 |
« Reply #8486 on: January 28, 2012, 01:50:40 AM » |
|
lol yeah this problem popped up after Kryal updated the way facepoints were read in the source.
Btw, almost have BB ready for release (actually, it technically IS ready), but I want to figure out what's up with SCN0s changing in file size after being rebuilt and figure out what's wrong with flat models.
Sounds good to me. By the way, couldn't I use the Brawlbox's source code to read already defined file structures? You left pretty thorough notes.
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8487 on: January 28, 2012, 03:46:34 AM » |
|
Long time no see, and I still can wish whenever there is going to be the complete support for .brsar archives...
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8488 on: January 28, 2012, 06:28:19 AM » |
|
hey BJ...
what differences are there in v10 MDL0's compaired to V11??
|
|
|
Logged
|
|
|
|
|
|
 |
« Reply #8489 on: January 28, 2012, 07:02:51 AM » |
|
@BJ Thanks for reply. As Xiggah said,0.63d could show the model properly,so I will try to find the bug in your source code comparing to 0.63d source.
|
|
|
Logged
|
|
|
|
|
|