Brawlbox Resources & History

[xxmasal22xx]

successfully completed a vector session

>>> setWrite()
tmp set to write
>>> setVector([[1, 1, 1], [1, 1, 1], [1, 1, 1]], 0,1,0)
Vectors logged successfully
>>> closeWrite()
tmp sucessfully closed
>>> setRead()
tmp set to read
>>> getVector(0,1,0)
[['1', '1', '1'], ['1', '1', '1'], ['1', '1', '1']]
>>> closeRead()
tmp sucessfully closed

UV's still need to be tested though (for the channels)

What exactly does that mean though?

[DarkPikachu]

successful UV session (:<

>>> setWrite()
tmp set to write
>>> setVector([[1,1],[1,1],[1,1]], 2,0,0)
Vectors logged successfully
>>> setVector([[1,1],[1,1],[1,1]], 2,0,1)
Vectors logged successfully
>>> setVector([[1,1],[1,1],[1,1]], 2,0,2)
Vectors logged successfully
>>> closeWrite()
tmp sucessfully closed
>>> setRead()
tmp set to read
>>> getVector(2,0,2)
[['1', '1'], ['1', '1'], ['1', '1']]
>>> getVector(2,0,0)
[['1', '1'], ['1', '1'], ['1', '1']]
>>> getVector(2,0,1)
[['1', '1'], ['1', '1'], ['1', '1']]
>>> closeRead()
tmp sucessfully closed
>>>

reading the UV channels in any order works perfectly

the session above shows the data being logged to and returned from the tmp:
< uvs 0 0 1|1/1|1/1|1
< uvs 0 1 1|1/1|1/1|1
< uvs 0 2 1|1/1|1/1|1


this is for use with building plugins for my converter...
instead of handling the tmp directly, just simply use the functions and save yourself some work

up next is the transforms (after the primitives of course)

[BlueBrain]

is this for the converter, and does it mean u guys are making progress???

than, why is nobody working on the "save" and "export" options???
i thaught the import was already done...

[DarkPikachu]

I'm currently working on a method of simplifying my plugins,
as well as making it easier for others to build theirs...

I currently have to redo all my plugins >_>

as for exporting...

for me, all I have is a basic model with apparently inaccurate normals...
blender resets the normals when importing, making it appear like they work...

I'll have to figure out what's up >_>

importing isn't even nearly complete...
there's alot learned, but there's still alot more to learn...

[Segtendo]

What exactly does that mean though?

It's complicated stuff. I wouldn't understand it if he explained it

[xxmasal22xx]

I'm currently working on a method of simplifying my plugins,
as well as making it easier for others to build theirs...

I currently have to redo all my plugins >_>

as for exporting...

for me, all I have is a basic model with apparently inaccurate normals...
blender resets the normals when importing, making it appear like they work...

I'll have to figure out what's up >_>

importing isn't even nearly complete...
there's alot learned, but there's still alot more to learn...

You do realize that once BJ96 is done with the brawlbox dae to mdl0, we won't really need a UMC, only .dat conversion will really be needed....almost anything can be saved as a .dae from 3ds max, so converting the other formats would be a waste of time.....

[Tempo_]

I thought they were working together?

[DarkPikachu]

You do realize that once BJ96 is done with the brawlbox dae to mdl0, we won't really need a UMC, only .dat conversion will really be needed....almost anything can be saved as a .dae from 3ds max, so converting the other formats would be a waste of time.....

you're missing the point that there's more than just MDL0 files
not to mention the fact that Brbx only limits the possibilities atm..

my converter's only as limited as:
1 - the 3D editor you use
2 - the format of the exported file

DAE isn't the best format for supporting everything
BLEND tops that
3DS is even better than DAE

but here's another idea...
can Brbx import 8 OBJ files to use in place of the UV channels?
can Brbx export MDL0 to 3DS or BLEND?
I don't think so...

keep in mind...
you're talking to a self-taught game developer here

I havn't dev'd any games yet, since IDK all the tricks yet...
but I'm smart enough to know alot of the basics,
as well as how they work internally.

Kryal doesn't appear to be too smart in the game development area...
thus why he doesn't know too much about the formats...

Kryal only knows what the Wii SDK has to offer...
to Kryal: sry my friend... but there's alot more to learn than just that ^_^

I'm sure you guys will be using my converter just about as much as Brbx
so yes, there is a need for it

[xxmasal22xx]

you're missing the point that there's more than just MDL0 files
not to mention the fact that Brbx only limits the possibilities atm..

my converter's only as limited as:
1 - the 3D editor you use
2 - the format of the exported file

DAE isn't the best format for supporting everything
BLEND tops that
3DS is even better than DAE

but here's another idea...
can Brbx import 8 OBJ files to use in place of the UV channels?
can Brbx export MDL0 to 3DS or BLEND?
I don't think so...

keep in mind...
you're talking to a self-taught game developer here

I havn't dev'd any games yet, since IDK all the tricks yet...
but I'm smart enough to know alot of the basics,
as well as how they work internally.

Kryal doesn't appear to be too smart in the game development area...
thus why he doesn't know too much about the formats...

Kryal only knows what the Wii SDK has to offer...
to Kryal: sry my friend... but there's alot more to learn than just that ^_^

I'm sure you guys will be using my converter just about as much as Brbx
so yes, there is a need for it

I see your point, but why work on so many plugins at once, when the converter doesn't even run yet? Or am i mistaken that you arent working on plugins?

Also, i support you fully, and im not trying to discourage you, im just asking.

But if i were you, id research which model types are the best quality and implement those only, at least for now.

[DarkPikachu]

I see your point, but why work on so many plugins at once, when the converter doesn't even run yet? Or am i mistaken that you arent working on plugins?

Also, i support you fully, and im not trying to discourage you, im just asking.

But if i were you, id research which model types are the best quality and implement those only, at least for now.

the converter runs nicely... it's the plugins that do all the work.

the only problem I'm having with the converter is the multi-reference conversion...
(like my example way earlier that has 2 plugins that use the .dat format)

the GUI sets up right and everything works perfectly,
but when you click a button to select your conversion method, nothing happens or is set...



and yea, IK you're not trying to invoke my operations
I'm going through with this one way or another



and I see what you mean...
thing is, I'm using the LQ plugins for conversion testing to make sure everything works...

the HQ plugins will come after that...



and I'm not just ending at a simple conversion factor like MDL0 to OBJ
if I'm doing that kind of conversion, there will be some advanced methods involved

like exporting an OBJ for each UV channel...
or selecting weather to apply the transforms to a mesh...
or even to save a TMP dump of the bones on an OBJ export

the last option does get kinda complicated...
but basically, the TMP file will be re-imported to the converter.
the TMP will then reference the OBJ export and remap it before creating a HQ export.

now you see why I'm taking so much time developing this...
it's thinking about the implementations like that,
that slows down my progress with my converter.

just be glad I'm not selling my converter
it's not always the pricey stuff that's the good stuff...

just look at Blender

[ForOhFor Error]

I suggest using a command-prompt style thing first, then modifying it to use a GUI. GUIs aren't as important as the actual program. And tkinter can be..... resistant.... with button commands

>.>

[DarkPikachu]

I suggest using a command-prompt style thing first, then modifying it to use a GUI. GUIs aren't as important as the actual program. And tkinter can be..... resistant.... with button commands

>.>

IK what you mean...
I'm so freakin close to finishing it though DX

the farthest I've gotten it is to set the var to the value of the last button
(the button command initiates as the button is drawn)

I could prbly get away with using Radio buttons though >_>

meh...
I'm not worried about that now anyways...
everything else works:
0-reference and single-reference conversion
fixed the bug that required you to type the extension of the export file

up next is handling multiple files...

I'm more focused on the plugins atm
mainly GlobalTMP.py which is the heart of the conversion (the bottleneck)
^it contains functions that send and return formatted data the TMP

[BlackJax96]

is this for the converter, and does it mean u guys are making progress???

than, why is nobody working on the "save" and "export" options???
i thaught the import was already done...

I am working on save and export...
We're not working on the same program, but we're cooperating and sharing information that we figure out.

I wouldn't just randomly get a dae to import and then ditch the flipping save option...

[ForOhFor Error]

Basically, most (if not all) of the MDL0 info is required to save and export, which are basically the same thing.

It's not saving itself, just that the MDL0 has some values that aren't compatible with brawlbox, and thus it throws a bunch of errors that prevent it from saving.

Right?

[BlackJax96]

Basically, most (if not all) of the MDL0 info is required to save and export, which are basically the same thing.

It's not saving itself, just that the MDL0 has some values that aren't compatible with brawlbox, and thus it throws a bunch of errors that prevent it from saving.

Right?

No. Here's the problems:

- Each node needs to calculate its own size by taking data from Brawlbox and arranging it in the mdl0 format. If this length is off, the next node's write address will start IN that node's "space" in the mdl0 file. The size calcualating isn't finished with Polygons, Shaders and (I think) Materials. Definitions, Bones and Vertices/UVs/Normals write perfectly though

- Shaders and Polygon data isn't figured out 100%. How do we write it...?

- Most offsets that are set within a polygon or material depend on calculating the size of the node, which isn't done yet.

- The mdl0 properties don't write. I'm trying to figure this out, I have no clue why O.o

- Probably some other stuff I'm forgetting so don't quote me and say that this is all that's left