User talk:Iritscen/Archive1

General Talk

Chapters and added value

Flipping through the stuff as I updated the page layout, I was really impressed with the quality of some of the "added value".

Keep up the good work, dude. I'm sure the chapter pages will grow (just a little bit) to be brilliant appetizers for all the rest.

geyser 03:38, 18 February 2008 (CET)

"I'm sure the chapter pages will grow (just a little bit) to be brilliant appetizers for all the rest." That's what I'm hoping; I just spouted some random stuff off the top of my head as I made each chapter's Added Value section, so there's plenty of room for corrections/additional insights. --Iritscen 15:48, 19 February 2008 (CET)

Here's an interesting article: Starbucks offers 2 hours free wifi each day. https://usatoday30.usatoday.com/money/industries/food/2008-06-02-starbucks-wifi_N.htm

Also, this site may help: https://www.wififreespot.com/

So now you have no excuse for not hanging out at the OCF and the wiki, during your move :-)

Sorry, I didn't know where else to put this, the Blender thread was getting long.

EdT 00:25, 4 June 2008 (CEST)

Aw, Ed... I kinda liked the idea of Iritscen taking up iPod therapy ^_^ --geyser 12:56, 4 June 2008 (CEST)

It's as geyser says, being restricted to my little iPod keyboard will do wonders for my verbosity. Suddenly I'll have to get right to the point and not write rambling diatribes. Seriously, I will probably take my laptop down to the library once in a while to use their free wi-fi (more of a library person than a Starbucks person; I don't even drink coffee). But I'm kinda lazy and rarely feel like unhooking my 'Book from all my stuff and schlepping it downtown. My iPod can get wi-fi right in my backyard, so I'll probably use that most of the time. --Iritscen 15:25, 4 June 2008 (CEST)

It's your mind I have trouble reading, geyser ^_^ --Iritscen 19:00, 3 June 2008 (CEST)

Quite. Your attention span is killing me. --geyser 22:35, 5 June 2008 (CEST)

Your incessant criticism is killing me. --Iritscen 22:57, 5 June 2008 (CEST)

Seriously, if you have time, can you write an AE wiki tutorial about how you modified Griffin's head --EdT 06:41, 5 June 2008 (CEST)

Quite. "How to FU Griffin's head BAR: a Blender tutorial by Iritscen". Definitely looking forward to it. --geyser 22:35, 5 June 2008 (CEST)

...Are you saying you don't agree with a modeling decision I made with Griffin, or that I FUBARed the actual model file? Choose your words carefully, friend. --Iritscen 22:57, 5 June 2008 (CEST)

I complied this version of AETools on my MacBook, hopefully, it works better for you. http://drop.io/EdT_OniFiles/ (dead link) Also be sure to get the latest version of OniSplit

EdT 02:12, 11 June 2008 (CEST)

I have written a first draft of a tutorial that is aimed at total newbies to 3D work and to Blender. It's currently a subpage at User:Iritscen/BlenderTutorial [This was deleted after languishing unfinished for years. --Iritscen]. It can be left there until done or I can finish it after someone moves it somewhere. I'm basically leaving that to geyser or someone else with the time to think about where it should go (but I know you have your strong views on how pages should be organized, geyser, so I imagine you should be the one to find a place for it). Please read the comments hidden with the  tags, too. --Iritscen 17:37, 11 June 2008 (CEST)

Browsing Flags

Landing from geyser's talk page, I found this script I made a couple of years ago. Its a modified version of OniMenu with just the flag browser part. http://edt.oni2.net/files/FindFlags.bsl Put it in any folder, move the current scripts somewhere else. Do a run back kick, then Crouch to enter the flag browser. The flag location is read from top to bottom. Then use the move keys to select the digits. Forward moves up, Back moves down. Left decreases the number, Right increases the number. Another thing, the global folder does not work on the Mac. EdT 07:13, 24 August 2008 (CEST)

Oh, cool, I'll give this a try. And re: "the global folder does not work on the Mac": D'oh! I probably read that at one point and then forgot. I wonder why I even have one if it doesn't work. --Iritscen 16:05, 24 August 2008 (CEST)

Hacking Multiplayer

Who here was involved with that effort to hack multiplayer into Oni?

Memory search: Alloc, Kumo, typhen (leader) and me.

Programs: typhen (Onyx/OnyxPatcher), neonew (OniHook)

How was the multiplayer actually supposed to get implemented into Oni?

Overwrite the memory at runtime.

How much was accomplished?

Some memory findings (pointers, player/enemy values, ...). (All?) results are stored here (Used program: TSearch).

What were the obstacles?

Working in the memory in general

Find the pointers (because the pointer position varies from OS to OS and from level to level).

Time (as usual).

typhen stopped his efforts on the project in August of 2005 for real life (girlfriend).

Ssg 00:25, 15 February 2008 (CET)

Kumo contributed some pseudonetcode in C++ that was supposed to interface with Onyx.

Alloc's OniTrainer implemented most of the gathered knowledge as the project went.

(OniTrainer had no network component, but it was a good tool for experimentation.)

The problem with TSearching was with all the big dynamically allocated structures.

It was a rather crazy idea to figure out those structures without disassembling...

I think the project started in April/May 2005, so it spanned the summer of 2005.

neonew's OniHook was totally independent of Onyx, so it's another project, sorta.

I'm not sure whether neonew disassembled Oni's engine in order to do the hooking.

A fair amount of Oni's engine has been disassembled since, by both SFeLi and Neo.

The structures responsible for the "game state" and "character state" are known.

geyser 02:04, 15 February 2008 (CET)

Some history:

typhen came up with the project in December of 2004. The first steps in the memory were made with RAMCheat. In January of 2005 typhen found the (great) program TSearch and the real memory search began. In April of 2005 geyser joined the Oni community and two or three weeks later the Ikonboard-based Oni forum crashed. (Because of too many verbose postings by him. :p *just kidding* ;-)

Unfortunately Harry never made this forum available as an archive.

Ssg 11:57, 15 February 2008 (CET)

The crash in April 2005 was supposedly due to me posting over a bad connection, which corrupted the database.

My impression is that the actual project started in May 2005 and thus is largely covered on the after-crash forum.

That's where you can see typhen and Kumo exchanging pseudonetcode, typhen and me talking about sync philosophy...

geyser 12:22, 15 February 2008 (CET)

Thanks for the info, guys. And sorry for being something of a jerk yesterday, geyser. Now, you said that the structures for game state and character state are now known -- are you referring to runtime variables? I don't see where those are documented in the wiki, unless this sort of page covers that information. Is that whole structure just loaded into memory to be worked with at runtime, and do we know where in memory to look for it, or is that where the process became difficult, due to that whole "dynamically allocated" structure that you mentioned? --Iritscen 16:42, 15 February 2008 (CET)

"And sorry for being something of a jerk yesterday, geyser." Sigh. I just don't understand why you avoid gathering first-hand knowledge.

Since you have that much free time, why not really come to terms with the object you want to provide accurate documentation for? Sigh.

I must say you still post and edit a wee bit too compulsively (a hyperactive kind of hyperdedication), and with not enough second sight.

Sure, the wiki needs regular editors, but you pretty much "jumped on it like an oversexed hippo" (C) Bungie. Hope it'll wear off somehow.

^_^

The disassembled engine is only documented in private databases, and we do not plan to publish those in any foreseeable future.

The "game state" is a huge chunk of data holding various runtime variables and structured objects (other, big chunks of data).

In particular, the game state structure holds a dynamically allocated array of character objects, each with a character state.

The character state holds various runtime variables specific to a given character, much more than the static game content.

Dynamical allocation means that the space required for the structures is not part of the EXE; it's requested at runtime.

Depending on the history prior to the allocation, the dynamically allocated space may end up at a different location.

The ONCC has little to do with "character state". In fact, the character state holds a mere link to the current ONCC.

geyser 15:43, 16 February 2008 (CET)

Importing from Blender

This is the place where EdT tells me what was wrong with that Griffin model I gave him. :-) What did you have to do to get it imported? (I know you already told me some of this, but let's state it here to lay the groundwork for the discussion.)

--Iritscen 15:59, 2 June 2008 (CEST)

General note 1: please provide links to every file you "cite" as an example, because "I extracted Motoko from the files you posted" or "geyser's earlier copy had triangles connected" just isn't informative enough. "Help us help you help us all."

General note 2: please stop guessing and start looking for systematic ways of investigating problems, because stuff like

"Its hard to say where the problem is, it could be Cheetah3D or it could be FBXConverter. All I know, is that the model's triangles are disconnected once I have it in Cheetah3D"

and

"Hmm, I guess Blender's exported DAE might have had a problem that Cheetah only noticed upon exporting; that almost sounds more like a Cheetah problem, though. Maybe it's both program's faults, technically."

is just not good for you.

geyser 07:01, 3 June 2008 (CEST)

geyser, geyser, geyser. Although I didn't strictly label it as such, this was really going to be a discussion between Ed and myself (see my bold italics). The reason I didn't send you the files I was working with was so that I could focus on problem-solving. So when I used terms like "geyser's earlier copy", Ed knew exactly what I meant, because this dialogue was picking up from PMs we were exchanging. Now you've come in here telling us how to talk about stuff, and the page is all gummed up. I'm the one who should be "meta-sighing" here. I have little time for these games, as this is my last week on the Net for the next month, I barely have any time this week at all, and *all* I want to know is how to get my own models into Oni. Your comments so far are largely distracting from our efforts. --Iritscen 16:02, 3 June 2008 (CEST)

This discussion is a public follow-up to your PM exchange, and if you mean to lay a solid groundwork for it, no detail is superfluous even if you're only talking to Ed. Precision is what enables expert troubleshooting and saves everybody's precious time. --geyser 17:31, 3 June 2008 (CEST)

Where do I start? :-)

Here's the basic workflow I use for Blender:

Export from Oni using AE Tools, option for Blender.

Import into Blender, using Collada 1.4

The 3D model will appear in a standing position. Do not change the rotation or position of the body parts.

Interesting. Griffin was always standing up, but when I extracted Motoko from the files you posted, and brought her into Blender, she had her legs behind her head! (Get your mind out of the gutter!) All her limbs were pointing up above her head. Have you seen that happen? What does that indicate? --Iritscen 21:08, 2 June 2008 (CEST)

That's how the body looks like when the rotation of all the body parts is set to 0 on the x,y,z axis, also this is known as the default orientation. I believe that when a body part is selected and you type "n" a window appears showing the properties such as position, scale, rotation. EdT

For further reference, see HERE and HERE. --geyser 07:01, 3 June 2008 (CEST)

Okay, I thought that might be what zero rotation looks like. Now, are you saying that if a model imports like that, I shouldn't rotate the parts to more normal angles? Because I did that for Motoko. Did that cause a problem when you went to import her into Oni? --Iritscen 22:06, 2 June 2008 (CEST)

Yes, so I just copied the head from your files and pasted into my original one. Also, the head's center point was off, so I had to correct it. EdT

Actually, everything but Griffin's head is untouched and 100% correct, so you can work with Iritscen's file, without pasting the head elsewhere. geyser 07:01, 3 June 2008 (CEST)

geyser... you're looking at Ed's fixed version, aren't you? I refused to link to mine because it was so messed up. If the copy you're looking at has correct part names, then it's not the copy I was working with. It would be a waste of time to examine that model and fix every problem when Neo has already fixed the export bugs and newly-made exports are fine. --Iritscen 16:02, 3 June 2008 (CEST)

No, I'm looking at this one (https://www.sendspace.com/file/rl6zre, dead link). As far as I can tell it's the exact same "flawed" version as you gave to Ed, and apart from the head name/hierarchy/placement (and the head mesh per se) there's nothing wrong with that model. Oh, and I still don't like how you blame OniSplit (version number?) for abstract bugs. --geyser 17:31, 3 June 2008 (CEST)

Whoops, I forgot Ed linked to my uploaded flawed model. See below for my answer on the "abstract bug" part. --Iritscen 19:00, 3 June 2008 (CEST)

Make the changes.

Export from Blender, Collada 1.4, options: triangles, disable physics, current scene. (I'm doing this from memory, I do not have access to Blender at work. will correct if necessary)

Import to Oni, using AE Tools.

Things to remember:

Each body part has a center point, when exporting from Oni as Collada, these center points are at the correct location. However, if new parts are added, then the center point must be set. To set the center point, position the cursor at the correct location on the body part, you will need to adjust it on all 3 axis. Then go to the menu Object: Transform: Set to cursor. (from memory)

When replacing a body part, its important that its rotation matches the original part. Also, the name must be exactly as the one replaced. Finally, the parent/child relationship must be re-established.

The notion of rotation matching is a bit fuzzy here, there, and everywhere. You're not making it clear what to do about rotations that don't match. --geyser 07:01, 3 June 2008 (CEST)

What went wrong with Griffin?

It appears there is an additional object connected to the new head, which needs to be deleted. The new head needs to be named correctly, it needs to be attached to the neck (parent/child). Finally the scale/rotation needs to match the previous head.

I did in fact forget to establish a link to the new head (I realized after I had sent it to you). I will have to examine the issue of scale/rotation to make sure it is set properly in Griffin, I don't know that part of the program yet. I can probably figure that out. --Iritscen 21:08, 2 June 2008 (CEST)

The scaling is fine. As for the rotation, the head is supposed to be aligned with the neck. So the only things that need to be done (apart from deleting the garbage object) are as follows: rename to "head"; reparent to "neck"; move/rotate into place; set center from cursor; "Object|Clear/Apply|Apply Scale/Rotation to ObData". --geyser 07:01, 3 June 2008 (CEST)

See, this is genuinely helpful. Thank you. --Iritscen 16:02, 3 June 2008 (CEST)

My pleasure, but it's not helpful until you acknowledge that it actually fixes the Griffin you've been working with, in-place. --geyser 17:31, 3 June 2008 (CEST)

Perhaps, since I was working with the .dae version, and not the original Blender file, I was not able to export to Collada, it kept failing on me. Not sure why...

Afraid you lost me here. DAE *is* Collada, but you said you couldn't export it to Collada.... --Iritscen 21:08, 2 June 2008 (CEST)

All I know is that after importing your .dae file, I could not export it out as .dae. EdT

Hmm, I guess Blender's exported DAE might have had a problem that Cheetah only noticed upon exporting; that almost sounds more like a Cheetah problem, though. Maybe it's both program's faults, technically. Well, in the future I will send you the .blend file if I need help, but hopefully I can make my own imports from now on. --Iritscen 22:06, 2 June 2008 (CEST)

Actually, the exporting error came from Blender itself, you can try it yourself. Import the .dae file you sent me into Blender, now try to export that file as Collada. EdT

Just to clear things up: Iritscen, Ed's DAE->DAE problem has nothing to do with Cheetah3D. He's just importing your .dae into Blender and trying to export it as .dae from Blender afterwards. I'm not sure why he's having trouble doing so, because for me that same operation works fine.

Still, I'd have a piece of advice as for exporting COLLADA from Blender: disable physics, use relative texture paths, and export selection only (select all body parts before exporting). The latter is to avoid accumulating layers of irrelevant and confusing metadata in the COLLADA file format.

geyser 07:01, 3 June 2008 (CEST)

I have yet to try to import my exported .dae back into Blender and export it again, so I can't say yet if it will work for me. But I will follow geyser's advice about exporting from now on. The point about selecting all body parts and only exporting the selection, in particular, may be key to avoiding future problems. --Iritscen 16:02, 3 June 2008 (CEST)

Well, DAEs exported with scene metadata are annoying more than anything else. It will justs end up as nested scenes when and if you import and reexport the DAE again, but it doesn't screw up the model in any way. For one thing, this (https://www.sendspace.com/file/rl6zre, dead link) includes scene data and I can work with it just fine.

Please note your misunderstanding of Ed's DAE->DAE problem as an example of a situation where early disambiguation wouldn't have hurt. Just because you and Ed have been talking about Blender and HD Griffin in private doesn't make you able to read each other's minds. --geyser 17:31, 3 June 2008 (CEST)

I know what you're talking about when you say the scene metadata is annoying, I tried to read the file once with the naked eye, and got pretty ticked off trying to make heads or tails out of all the nesting.

As regards my little misunderstanding about Ed's DAE->DAE problem, that was easily corrected by a short exchange between us. Even being as vague as you seem to think we are, we actually haven't wasted any real time due to misunderstandings so far. So we can at least read each others' minds enough that we don't have to spell out everything letter by letter. It's your mind I have trouble reading, geyser ^_^ --Iritscen 19:00, 3 June 2008 (CEST)

What did I do? I used Cheetah3D. I exported ONCCgriffin_generic as Collada, used FBXConverter to convert the file to .fbx. I also converted your new model to .fbx. I then copied the new griffin head to the griffin_generic fbx file, replaced the original head, set the correct rotation and parent/child relationship. Exported it out as .fbx, converted it to .dae using FBXConverter, then imported into Oni. Also, regarding the triangles not being connected in my model, I did not Optimize the model in Cheetah3D before exporting.

EdT 20:51, 2 June 2008 (CEST)

When you say you did not optimize the model... was that supposed to connect the triangles? Does Cheetah otherwise disconnect the triangles? That would be very odd. --Iritscen 21:08, 2 June 2008 (CEST)

Optimize in Cheetah3D connects the triangles, and a couple of others things, I don't remember right now. EdT

See, I just don't get that, because geyser's earlier copy had triangles connected. It concerns me that Cheetah would disconnect the triangles unless you specifically tell it not to. When you're working with the file in Cheetah, are the triangles already disconnected, or is that only happening when it exports? --Iritscen 22:06, 2 June 2008 (CEST)

What can I say? I didn't know there was a problem, until you pointed it out. Its hard to say where the problem is, it could be Cheetah3D or it could be FBXConverter. All I know, is that the model's triangles are disconnected once I have it in Cheetah3D EdT

You could shed some light on this mystery by uploading the FBX file output by FBXConverter. --geyser 07:01, 3 June 2008 (CEST)

Yes, EdT, this may be helpful. --Iritscen 16:02, 3 June 2008 (CEST)

it's important that its rotation matches the original part Conceptually, this has to do with the "center point": you have to define not only a position for it, but also a rotation, and thinking of it as a "point" can be misleading. I have no idea how Blender handles this exactly, but I'd be surprised if it was working with ill-defined frames of reference. Therefore the "center point" mentioned by Ed must have an adjustable orientation property.

Hmm, not sure I get this, but do I need to get it? As long as I alter polys and don't add new parts (which, yes, I did do for Griffin, but only to get his new head on the old body that was un-importable), do I need to worry about center points and rotations? As long as I don't change either of those? --Iritscen 21:08, 2 June 2008 (CEST)

That is correct EdT

do I need to get it? That's entirely up to you. Stuff like "bastardizing" can indeed be done without "worrying about center points and rotations". But without a solid notion of the "reference frames" (a.k.a. "systems of coordinates") involved, a major screw-up is only a matter of time. --geyser 07:01, 3 June 2008 (CEST)

only to get his new head on the old body that was un-importable Er? I'm confused again: what old body are we talking about, how was it un-importable, and how does this all fit in with you eventually combining that supposedly un-importable body with the new head? --geyser 07:01, 3 June 2008 (CEST)

Just to explain this once and for all: I exported Griffin. Months ago. OniSplit was still buggy in the area of exporting at the time. Stuff was messed up in the model, but that would only become known later. It wasn't anything that I could notice while working on it. Eventually I realized, from seeing Ed's bug reports on Neo's talk page, that my model was going to be trouble. So, last week, I used OniSplit 0.9.14 to export Griffin, and appended my old file with the HD head onto the imported new export. I deleted the head in the new export and put the HD head into place (but forgot to parent it). --Iritscen 16:02, 3 June 2008 (CEST)

That explains a lot, but the information is still incomplete without the version number of the OniSplit you used "months ago" and the way in which "stuff was messed up". Are we even talking about COLLADA? Didn't you start working on a Griffin imported from OBJ, before OniSplit even started supporting COLLADA? It may look like a detail to you, but it's very important that you remember. --geyser 17:31, 3 June 2008 (CEST)

I don't have an exact record of what version of OniSplit was used to export Griffin, or what month it was done in, but it was probably the end of March. And yes, I did in fact export Griffin as OBJ before the Collada support came along. The model on my sendspace account is in fact that model (imported to, and worked with in, Blender, then exported to DAE). Now, as far as the exact 'stuff that was messed up', all I can say is that I was reading Neo's talk page (which was completely different at the time), and my eyes were glazing over, because I had not delved into the technicalities and a lot of the exchange between EdT and Neo was like Greek to me, but I do remember reading about incorrect part names. I can no longer find that discussion in his page or any version of it in the past, but Ed can back me up on this, that he noticed that there were parts with names like "right right" instead of "calf right", etc. I believe there were other issues aside from naming, but I also felt that, even if I didn't know what the problems were, they were out there, lurking, and it was best to paste the HD head onto a new export. So, because I refused to let the old model's export problems trip me up (and yes, OniSplit was buggy, Neo will admit that), I never determined exactly what those problems would have been. --Iritscen 19:00, 3 June 2008 (CEST)

What went wrong with Griffin? If that's of any help, you can let me (or Neo) try and import him any time at all. When in trouble, there's nothing wrong with asking those familiar with OniSplit and/or the COLLADA format to have a look. What kind of masochist are you? If you're scared of me, try and "use" Neo. He may not help you all the way out, but he won't bite, that's for sure.

*shrug* Ed just seemed to be the person to ask. We're using the same programs, and he had clear experience in importing models already. --Iritscen 21:08, 2 June 2008 (CEST)

From what I have seen, Ed was quick to turn away from Blender and has since been working with Cheetah3D. No to say that he can't be of any help at all, but when it comes to Blender's COLLADA plugin and possible issues with that, the right person to ask is Neo, who has taken the time to look at the plugin's (buggy) source to make sure Blender is decently compatible with the flavor of COLLADA used by OniSplit. --geyser 07:01, 3 June 2008 (CEST)

Oh, and I'm also very confused about work on Griffin began so long ago that OniSplit had some model exporting issues, which are now a part of the model, so the model is not able to be imported as is ... No bug report at all? Just what "issues" could we be talking about? Are those assumptions, maybe? Well?

geyser 20:16, 2 June 2008 (CEST)

The reason I didn't attempt a bug report was that I suspected the problems were extensive (wrong part names, for one thing, but probably more), and it was pointless to analyze the Griffin model I was working with as long as the head could be stuck on a new export of the original body. I knew I was going to do that so I never asked anyone to analyze the body I was working with (after all, only the head was changed and only the head mattered). Then, I *did* ask for a bug report from Ed by sending him my model, since I didn't know enough to find those bugs myself. --Iritscen 21:08, 2 June 2008 (CEST)

Meta-sigh. There is nothing wrong with the Griffin model you were working on: it's 100% consistent with "a new export of the original body". It is not corrupt in any way, except for the hierarchy of the head, and that one can be fixed in-place without sticking anything anywhere.

Either way, in the future it'll be great if you don't casually attribute non-existing "issues" to OniSplit as if that was a fact. We have respect for user error; in return, please at least give the benefit of the doubt to the tools at your disposal (it's about your credibility, not about offense).

--geyser 07:01, 3 June 2008 (CEST)

You probably get this by now, but the model that's "100% consistent" with a new export *is* a new export (except the HD head). --Iritscen 16:02, 3 June 2008 (CEST)

Yes, but (see above) this still isn't telling me whatever was wrong with the old export: "wrong part names, for one thing, but probably more"... "probably"? Just what kind of suspectedly extensive problems were those. Please cope with my curiosity. --geyser 17:31, 3 June 2008 (CEST)

(Answered above.) --Iritscen 19:00, 3 June 2008 (CEST)

geyser, sorry my terminology is not correct. What I called "center point" is the point where the body part will rotate around. I used "Rotation" as the orientation of the body part in 3D space. When the rotation for all the body parts is 0 for x,y,z, then the pose of the model is the default orientation. But since the pose in Blender is a standing pose, the rotation of the body parts is not 0,0,0. So if you replaced the head, with one that had a different rotation (even though it looked the same), the head will appear wrong in Oni.

That's where the catch is, Ed: are you sure you understand how it is possible that 2 heads have "different rotations" even though they "look the same"? And in what sense is the rotation of the body parts not 0,0,0 for a standing pose? Think "local reference". --geyser 07:01, 3 June 2008 (CEST)

Blender designers do a great job at confusing people, in the way only global orientations can be seen and edited, but it's the local reference of each body part that matters, and the local orientations of most body parts (e.g., the head) are 0,0,0. --geyser 07:01, 3 June 2008 (CEST)

Here's the link to Iritscen's Griffin: https://www.sendspace.com/file/rl6zre (dead link) Also, you can find my version of Griffin here: http://drop.io/EdT_OniFIles (dead link)

EdT 20:51, 2 June 2008 (CEST)

Thanks, Ed. Your TRBS is OK, I guess (as for the head mesh, that's a completely different story). The problematic .dae has been an opportunity to check out just what tool Iritscen is "forced" to work with. I'm definitely appalled at how much Blender sucks, from the confusing/confused design/philosophy to the online manual. In particular when it comes to coordinate systems and transformations, it's unspeakably clumsy. Of course, there are some decent workarounds (see 5-step instructions for fixing Griffin's head above), but that doesn't cover every real-world situation, and every such "exception" will be a little big nightmare. Maybe for HD modding or bastardizing the workflow won't be too lousy, but it will never soar, that much is certain. --geyser 07:01, 3 June 2008 (CEST)

Yes, the design is crappy (but don't tell them that, they have blinders on and can't see the appalling stupidity of things like no copy/paste command). Yes, the wiki-manual is crappy. But I think that we are actually close to a perfectly serviceable workflow. I used AETools this morning to export Griffin from the .oni file that Ed has up on his drop.io page, and it looks correct in Blender. I still have to test what happens when I edit the file (thus saving it in the .blend format), then export it to .dae from Blender, then import it into a .oni using AETools. It may very well work. Don't nay-say so much, geyser. Griffin in specific has had issues that will not ever come up again in the future. I still have to discuss him here because I need to fix the model for further work going forward, but our discussion here about workflow is somewhat a separate topic because it assumes that the OniSplit export is not buggy, etc. That's okay, because the OS export isn't buggy anymore. --Iritscen 16:02, 3 June 2008 (CEST)

Blender is irredeemable beyond any complaint to developers. But I'll help you out if you choose to stick with it.

Calling OniSplit export buggy without a proper bug report or even a version number... Final credibility warning.

I need to fix the model for further work going forward "Yes you do... perhaps more than you know..." (C)Kerr

geyser 17:31, 3 June 2008 (CEST)

If you are insinuating something, please spell it out at Image_talk:Poly_Mods-Griffin_Master_Comp.jpg. --Iritscen 19:00, 3 June 2008 (CEST)

P.S. to geyser: I did offer these files to you by saying you could ask Ed for them... so, you can't accuse me of withholding them from you since I only just made them available to anyone at all, and you were included in that offer. --Iritscen 21:08, 2 June 2008 (CEST)

I wasn't accusing anyone of anything right there, but you have to admit that "oh, just go and ask Ed if you really wanna have a look at it, but I really wouldn't bother if I were you" is not the same as "here it is". Also, it's not just about "offering" stuff to me; this is typically the case where I'd address Neo directly, at the first sign of trouble... "if I were you". --geyser 07:01, 3 June 2008 (CEST)

Where do I begin? There is much being discussed here, so I'm just going to put all my comments in one area.

Regarding the "Rotation" terminology, this is my point of reference: I exported ONCCgriffin_generic from Oni for Blender, get standing pose, select head, look at the Transform Properties I see RotX 90.00 RotY-90.00 RotZ 0.00 In comparison, Iritscen's griffin head has the properties RotX -0.08 RotY-1.993, RotZ 3.315. So even though the head looked the same, the Rotation properties were different. So if we were to export that file to .oni, would the head be in the correct position?

Now my problem with exporting Iritscen's .dae I get this error from Blender (I followed what geyser stated about the export settings)

 FEEDBACK: Illusoft Collada 1.4 Plugin v0.3.159 started
 Traceback (most recent call last):
 File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/cstartup.py", line 609, in ButtonEvent
 File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 63, in __init__
 File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 71, in __Export
 File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 346, in Export
 File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 516, in SaveToDae
 File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 1879, in SaveSceneToDae
 File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 2848, in GetBindMaterials
 File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 3106, in SaveToDae
 File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 2911, in AddImageTexture
 AttributeError: 'NoneType' object has no attribute 'name'

For the disconnected triangles, I found the issue. Converting from .dae to .fbx no disconnected triangles, going from .fbx to .dae, disconnected triangles. Here are all the files: http://drop.io/EdT_OniFiles griffin_dae_fbx.zip (dead link) The .dae/.fbx files with ORG in the name are the original .dae and converted .fbx. The ones with 2 is the .dae converted from the .fbx and back to .fbx.

One other thought, the messed up names, I had that same problem when importing the ONCC as an object into Blender (Prior to the Collada option). The names of the body parts would be misapplied in Blender, so the head would be named something else, I don't remember the details. So that's probably what Iritscen used when he first started to modify Griffin's head

EdT 18:51, 3 June 2008 (CEST)

So, um, what can we do about the FBX->DAE problem? I just noticed that the Griffin model in your drop.io TRBS.oni file, when exported to .dae, has twice as many vertices as my original file (on the sendspace account). The face count is largely the same (= no extra triangles, just extra points). Many connections between triangles are broken, though not all of them. You can see for yourself by exporting the .oni to .dae and opening it in Blender. As long as you're in Object Mode, the stats at the top-right (V-xxxx and F-xxxx) tell you the vertex and face counts. You can also start grabbing points and trying to move them, to see how many are disconnected. If *all* of them were broken, it would mean 3-5 times as many vertices; some triangles *are* still connected to others. Still, that means Oni is taking way more of a hit than it needs to. When I used AETools to make your fixed HD Griffin cel-shaded, it worked nicely (well, the edge color is not black, but it actually looks kind of cool to me). But that model has twice as many faces (natch), as well as still having twice as many vertices due to the disconnect issue, so it's gotta be hitting Oni's engine pretty hard.

--Iritscen 15:35, 4 June 2008 (CEST)

The easiest way to overcome the FBX-DAE problem is for me to learn Blender! Seriously, if you have time, can you write an AE wiki tutorial about how you modified Griffin's head, so that even a dummy like me can understand it. Please include what tools you used, how to access them, how to increase the polygons for the "HD" look and so on. (If possible screenshots would also be helpful) I know that a tutorial geared toward Oni 3D modeling will be very valuable.

EdT 06:41, 5 June 2008 (CEST)

I can certainly do that at some point, although I'm a tad hesitant to teach anyone Blender when it's giving me so much trouble (see below). Although, just to be fair, Blender's weird design is not causing any problems. The problems are all coming from the third-party Collada plug-in. If we can iron out the problems I'm going to report, then, sure, I'll make an Oni-oriented quick tutorial for Blender on the wiki. --Iritscen 16:57, 5 June 2008 (CEST)

Okay, some of this is in response to geyser/Ed's comments above, but I'm throwing it all down here to keep things simple. Hopefully you can add your responses down here too, since that top part is pretty crazy now.

General Notes: These attempts all used the latest AETools and OniSplit v0.9.14. They use Ed's model, not my working model, which DOES have wrong part names, geyser (the word "iteration" and some other junk is part of each part name). Also, the files linked to below are named [x].dae and [x]2.dae to differentiate, but when I worked with them in the importing-to-Oni process, they were named identically.

Working with HD Griffin
Attempt 1

Used AETools to extract Ed's TRBSgriffin_body_high.oni using "for Blender" option.
Imported into Blender, did nothing with it except select all 19 bones.
Exported to Collada format using "only current scene", "disable physics", "only export selection", and "use relative paths" (as well as "triangles" option) per geyser's suggestion.
Used AETools' Import and Rebuild to bring .dae back into Oni.

Notes: My Blender-exported .dae is 744KB, but the original .oni-exported .dae was only 228KB. Also, I later imported the Blender-exported .dae back into Blender itself and the model was horribly messed up ([1]).

Results: Oni immediately crashes when I shapeshift to Griffin.

Attempt 2

Used AETools to extract Ed's TRBSgriffin_body_high.oni.
Used AETools' Import and Rebuild to bring .dae back into Oni.

Notes: This is simply testing that AETools/OniSplit actually are working with themselves and that their input/output are compatible.

Results: Success, not that this really helps me when I am trying to edit the model in Blender and bring it into Oni.

Attempt 3

Used AETools to extract Ed's TRBSgriffin_body_high.oni.
Imported into Blender, did nothing with it.
Exported to Collada format using "only current scene", "disable physics", and "use relative paths" (as well as "triangles" option).
Used AETools' Import and Rebuild to bring .dae back into Oni.

Notes: The Blender export is still very large (748KB). But this time it imports back into Blender properly, at least.

Results: Same crash as in Attempt 1.

Attempt 4

Used AETools to extract Ed's TRBSgriffin_body_high.oni.
Imported into Blender, did nothing with it.
Exported to Collada format using "only current scene" and "disable physics" (as well as "triangles" option).
Used AETools' Import and Rebuild to bring .dae back into Oni.

Notes: Blender export still 748KB.

Results: Same crash.

Working with Motoko
Attempt 1

Used AETools to extract dae. for Blender from geyser's TRBSmotoko_body_high.oni.
Imported into Blender, changed nothing.
Exported as .dae using "triangles", "disable physics", "only current scene", "use relative paths".
Halted process here, as it has the same issues as the Blender-exported Griffin and failure is certain.

Notes: Second .dae is again much bigger than first; examining it, I see arrays of UV coord.s that are a few times larger than the first .dae's versions. Also, hundreds of normal coord.s have been added for each part, where before there were none. Also, the arrays found at places like "neck-geo-position" (now marked with <p></p>) seem to be in a completely different format than in the original .dae (series of whole numbers, always positive, rather than the +/- floating point numbers in the original .dae). See http://www.drop.io/blenderisdumb (dead link) for the first and second .dae files.

Working with Barabus
Attempt 1

Used AETools to extract ONCCbarabus.oni for Blender from level0_Final.
Imported into Blender, changed nothing.
Exported using triangles, disable physics, only current scene, relative paths.
Halted process due to seeing same issue with output.

Notes: Same issues as Motoko and Griffin with second .dae. See http://www.drop.io/blenderisdumb (dead link) for the two .dae files.

Okay, so my basic point here is, What are we gonna go about the screwed-up DAE output from Blender's Collada plug-in? --Iritscen 17:26, 5 June 2008 (CEST)

P.S.: If for some reason you want to post a file to that drop.io account, like maybe a fixed version of something, go to http://www.drop.io/blenderisdumb (dead link). --Iritscen 18:57, 5 June 2008 (CEST)

I'll run the same tests as you did and post my results. Note your links to the .dae have timed out, better change the links just to the drop.io folder.

EdT 20:24, 5 June 2008 (CEST)

Thanks and thanks, Ed. I didn't know those links would time out, at least until the account is deleted, which will be in a month (unless I renew). --Iritscen 20:41, 5 June 2008 (CEST)

Here's the results of my brief test:

Working with Barabas same procedure as Iritscen's Attempt 1:

Original ONCCbaraus.dae exported from Oni 144KB, exported from Blender 284KB.
Imported back to Oni, works fine.

EDIT: Added ONCCbarabus_EdT.dae to http://www.drop.io/blenderisdumb (dead link)

Working with HD same procedure as Iritscen's Griffin Attempt 4:

Original TRBSgriffin_body_high.dae exported from Oni 228KB, exported from Blender 436KB
Imported back to Oni, once Griffin comes into view (he was off camera, but once I turned toward him), Oni crashes.

The TRBSgriffin_body_high_EdT.dae was added to http://www.drop.io/blenderisdumb (dead link)

Crash report:

   Thread 0:
   srr0: 0x9000b348  srr1: 0x0000d030   cr: 0x24022024  xer: 0x00000000  lr: 0x9000b29c ctr: 0x9000b340
   r0: 0xffffffe1  r8: 0x00000000  r16: 0x00000000  r24: 0xf0182840
   r1: 0xf0182770  r9: 0x00000000  r17: 0x00000000  r25: 0x00000450
   r2: 0xa1b1c1d3  r10: 0x91444fa8  r18: 0x00006803  r26: 0x00006703
   r3: 0xf0182840  r11: 0xa0006a28  r19: 0x00000000  r27: 0x00000000
   r4: 0x03000006  r12: 0x9000b340  r20: 0x05c7f91c  r28: 0x00000000
   r5: 0x00000000  r13: 0x00000000  r21: 0x849336f2  r29: 0x03000006
   r6: 0x00000450  r14: 0x00000000  r22: 0x0063e508  r30: 0x03000006
   r7: 0x00006703  r15: 0x00000001  r23: 0x00000000  r31: 0x907de670
   0 -- 0x9000b348 -- _mach_msg_trap
   1 -- 0x9000b29c -- _mach_msg
   2 -- 0x907de998 -- ___CFRunLoopRun
   3 -- 0x907de29c -- _CFRunLoopRunSpecific
   4 -- 0x91458524 -- __ZN10HALRunLoop9OwnThreadEPv
   5 -- 0x914582c4 -- __ZN9CAPThread5EntryEPS_
   6 -- 0x9002bd08 -- __pthread_body

  Thread 1:
   srr0: 0x000ef5f0  srr1: 0x0200f030   cr: 0x44000220  xer: 0x00000004  lr: 0x000ef5e4 ctr: 0x900031c0
   r0: 0x44000220  r8: 0xd83c9f00  r16: 0x00000000  r24: 0x00000000
   r1: 0xbfffdc80  r9: 0x00000009  r17: 0x00000000  r25: 0x00195f6d
   r2: 0x00000020  r10: 0x015f2020  r18: 0x00000001  r26: 0x00000000
   r3: 0x00000000  r11: 0x001b9610  r19: 0x00000000  r27: 0x001c67bc
   r4: 0xbffff7ac  r12: 0x900031c0  r20: 0xbffff7ac  r28: 0x00003fff
   r5: 0x0b04d312  r13: 0x00000000  r21: 0x00000000  r29: 0xbffff9b8
   r6: 0xbffff9b8  r14: 0x00000000  r22: 0x000000ff  r30: 0x0b04d300
   r7: 0xbfffddc8  r15: 0x00000000  r23: 0xbffff9c0  r31: 0x000ef5e4
   0 -- 0x000ef5f0 -- _TSrContext_FormatString
   1 -- 0x000ef5e4 -- _TSrContext_FormatString
   2 -- 0x000b9770 -- _COrTextArea_Display
   3 -- 0x000b8e04 -- _COrConsole_Display_Messages
   4 -- 0x00062598 -- _ONiGameState_Display_Overlay_Elements
   5 -- 0x00062d28 -- _ONrGameState_Display
   6 -- 0x00003d48 -- _ONiRunGame
   7 -- 0x00004610 -- _ONiMain
   8 -- 0x0000470c -- _main
   9 -- 0x00002b40 -- __start
  10 -- 0x00002970 -- start

   Thread 2:
   srr0: 0x90054388  srr1: 0x0200f030   cr: 0x24008244  xer: 0x00000000  lr: 0x90070be8 ctr: 0x90054380
   r0: 0xffffffd9  r8: 0x91468918  r16: 0x00000000  r24: 0x00000000
   r1: 0xf0284b00  r9: 0xa0001fac  r17: 0x00000000  r25: 0xa00009dc
   r2: 0x00000001  r10: 0x00ac5323  r18: 0x00000000  r26: 0x0063fce4
   r3: 0x00000031  r11: 0xa0006be0  r19: 0x00000000  r27: 0x0063fd10
   r4: 0x00002c03  r12: 0x90054380  r20: 0x00000000  r28: 0xf0284bb0
   r5: 0x00000000  r13: 0x00000000  r21: 0x00000000  r29: 0xa0001fac
   r6: 0x00ac5323  r14: 0x00000000  r22: 0x00000000  r30: 0xa0001fac
   r7: 0xf0284d58  r15: 0x00000000  r23: 0x00000000  r31: 0x900709dc
   0 -- 0x90054388 -- _semaphore_timedwait_signal_trap
   1 -- 0x90070be8 -- _pthread_cond_timedwait_relative_np
   2 -- 0x914696ac -- __ZN7CAGuard7WaitForEy
   3 -- 0x914695bc -- __ZN7CAGuard9WaitUntilEy
   4 -- 0x91467800 -- __ZN11HP_IOThread8WorkLoopEv
   5 -- 0x91467498 -- __ZN11HP_IOThread11ThreadEntryEPS_
   6 -- 0x914582c4 -- __ZN9CAPThread5EntryEPS_
   7 -- 0x9002bd08 -- __pthread_body

   Thread 3:
   srr0: 0x9003288c  srr1: 0x0000d030   cr: 0x82000002  xer: 0x00000000  lr: 0x33332814 ctr: 0x90032880
   r0: 0x00000007  r8: 0x00000000  r16: 0x00000000  r24: 0x00000000
   r1: 0xf00807d0  r9: 0xa0010204  r17: 0x00000000  r25: 0x00000000
   r2: 0x000000dc  r10: 0x90032824  r18: 0x00000000  r26: 0xf0080bec
   r3: 0x000006de  r11: 0x42000008  r19: 0x00000000  r27: 0x000ef5f0
   r4: 0x00000000  r12: 0x90032880  r20: 0x00000000  r28: 0x00000001
   r5: 0x00000000  r13: 0x00000000  r21: 0x00000000  r29: 0x000006de
   r6: 0x00000000  r14: 0x00000000  r22: 0x00000000  r30: 0x00000002
   r7: 0x00000000  r15: 0x00000000  r23: 0x00000000  r31: 0x333325c8
   0 -- 0x9003288c -- _wait4
   1 -- 0x33332814 -- _OCCHandleException
   2 -- 0x33331e34 -- _OCCExc_catch_exception_raise_state_identity
   3 -- 0x333329cc -- __Xexception_raise_state_identity
   4 -- 0x33332adc -- _OCCExc_server
   5 -- 0x33331ee0 -- +[OCCCrashCatcher(MachPrivate) _handleExceptions]
   6 -- 0x92bf6118 -- _forkThreadForFunction
   7 -- 0x9002bd08 -- __pthread_body

   Thread 4:
   srr0: 0x9002c3c8  srr1: 0x0000f030   cr: 0x24000084  xer: 0x00000000  lr: 0x90030eac ctr: 0x9002c3c0
   r0: 0xffffffdb  r8: 0xf0101a00  r16: 0x00000000  r24: 0x00000000
   r1: 0xf0101c80  r9: 0xa0001fac  r17: 0x00000000  r25: 0x00000000
   r2: 0x00000001  r10: 0x90a3f628  r18: 0x00000000  r26: 0xa0000cdc
   r3: 0x00002d03  r11: 0xa0006bf4  r19: 0x00000000  r27: 0x00623778
   r4: 0x00002e03  r12: 0x9002c3c0  r20: 0x00000000  r28: 0xa0001fac
   r5: 0x000003e8  r13: 0x00000000  r21: 0x00000000  r29: 0x006237a4
   r6: 0xffffffff  r14: 0x00000000  r22: 0x00000000  r30: 0xa0001fac
   r7: 0x000000ff  r15: 0x00000000  r23: 0x00000000  r31: 0x90030cdc
   0 -- 0x9002c3c8 -- _semaphore_wait_signal_trap
   1 -- 0x90030eac -- _pthread_cond_wait
   2 -- 0x92bfd284 -- -[NSConditionLock lockWhenCondition:]
   3 -- 0x001548a4 -- -[SoundChannelProcessor(Private) _processQueue]
   4 -- 0x0015483c -- -[SoundChannelProcessor processQueueForever:]
   5 -- 0x92bf6118 -- _forkThreadForFunction
   6 -- 0x9002bd08 -- __pthread_body

I think that your result with Griffin matches mine (didn't look at the crash report, but it sounds like the same issue, it crashes as soon as his model should be visible., but I am fascinated by Barabus actually working for you. Also, your second .dae for Barabus about half the size of mine, even though you followed the same steps. Maybe tomorrow I will post an actual video of what I am doing with Barabus, and also follow it through to trying it out in Oni to see if it really does crash as I assumed it would. I have a feeling that assuming Barabus/Motoko would crash based on Griffin crashing was a faulty premise, since we all know Griffin has the most issues. I guess I got tired of crashing Oni so I chickened out when it came time to try Motoko and Barabus with those bloated .daes.
P.S.: I can't figure out anything from that crash report, though maybe someone else can. Sometimes I can read something in them, but not this time.
P.P.S.: Thanks for putting your name in the filename you posted to the drop.io account, that will keep things from getting too confusing. --Iritscen 22:52, 5 June 2008 (CEST)

Update: I did try to use Barabus in Oni after passing him through Blender and back out to a .oni file, and I did crash. But, Ed, I would love to know why your 2nd .dae for Barabus was only 284KB when mine (as seen in the drop.io) was 480KB. I looked for your Barabus upload to the drop.io and I don't see it. Do you still see it up there? --Iritscen 18:28, 6 June 2008 (CEST)

Working with Blender part 2

Sorry, I don't know what happened with the drop.io upload, it should be up now, I also included an export from my MacBook, but there was no material difference between the PPC and Intel version of Blender.

However, in comparing your file, I found the reason why your file is larger, but not the cause. For each body part you have a section for color array, which mine does not:

<float_array count="912" id="mid-geo-color-array">1.00000 1.00000 1.00000 </float_array>

<technique_common>

</accessor>

</technique_common>

</source>

Note: There were a lot more "1.00000" in the float array but I deleted them to save space.

EdT 05:02, 7 June 2008 (CEST)

Ed, I see you're using a different version of Blender on your 2 Macs. Not that it should matter, but better be aware of that kind of thing, and maybe synchronize the Blender versions to rule out minor, distractive differences in the output. Another thing that definitely does matter is the version/features of Python, which Blender relies on for most of the import/export and even some internal stuff. Python scripts are more or less messy and may have issues with certain releases of Python: typically "too recent" Python versions shouldn't be a problem but, again, it's best if you know what your Python version is and say it out loud.

I'm rather surprised that you didn't figure out the basic reason for the crashes right away, Ed, because you've been there before: too many points (over 2048) for certain body parts. In the case of Iritscen's Griffin, there are 4457 points for the head in the TRBS, so it's no wonder Oni crashes when it comes to drawing him. As for the more specific reason why there are so many points, it's also something you've encountered before for your "own" Motoko: non-smooth normals, which results in a faceted look and makes the point count increase 6-fold or so. For Konoko this still works, even with cel-shading on, but with HD Griffin, well, you get 4457 points even without cel-shading: blam.

Now, this would all be perfectly manageable with OniSplit's -normals tag, which is supposed to calculate smooth normals and make those faceted models both lighter and better-looking. But there is one intriguing point: -normals fails to work with, e.g., the Barabas exported by Blender, i.e., he will yield a faceted TRBS with an exaggerated point count, whether you use the -normals tag or not. This may be due to a "feature" of the Collada plugin, but we're not sure yet: if it will require a new version of OniSplit; if it will require a new version of the Collada plugin; if Oni's models themselves have confusing mesh data (Barabas, for instance, has some weird thighs). Still investigating...

geyser 14:21, 7 June 2008 (CEST)

Well, geyser, as you stated in earlier posts, is that I shouldn't "guess" about why something is going on, but investigate it. So regarding Griffin's head, I did not have the time to investigate the issue. As you are aware, I can import Iritscen's Griffin into Oni without crashing, if I use Cheetah3D to export the model to fbx and then use FBXConverter to convert it to .dae. Also, I used the -normals options when creating the Blender version.

I was wondering why Iritscen's .dae version was larger, so that's what I looked into. That's when I did discovered that Iritscen's Blender .dae export is including the <source id="pelvis-geo-color"> for each body part which caused his .dae size to be much larger than the original .dae

Since I really don't use Blender anymore, I didn't have it on my Intel Mac, so I just got the latest version of Blender, just to see if it was the Intel version of Blender which was causing the larger .dae size (which it did not).

I had Python 2.3.3 on my PPC desktop (Now updating to 2.5.2), and Python 2.5 on my Intel Mac.

EdT 16:00, 7 June 2008 (CEST)

Collada import fixed in OniSplit v0.9.16

After testing the 3 post-Blender DAE provided by Iritscen (Barabas, Motoko, Griffin), it appears that only Griffin makes Oni crash as of OniSplit v0.9.15 (because the head ends up with 4457 points, and 4457>2048); for the other 2 models, the TRBS were faceted, but still well below the 2048 limit. It turns out that all the COLLADA files are OK (even if it's a shame what Blender does to normals): the actual problem was that OniSplit's [-normals] feature was implemented incorrectly and failed to eliminate the many duplicate vertices/normals/UVs.

The NEW VERSION (https://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniSplit/OniSplit|_v0.9.16.zip, dead link) does that correctly, and should work optimally with both the .dae exported by Blender and the ones generated from Cheetah-made FBX by Autodesk's converter. Be sure to use the -normals tag so that the not-quite-smooth normals in the DAE are ignored and 100%-smooth normals are generated instead: that's when the point count of the TRBS will be minimal. Thus, Barabas's head went down from 129 points to 128 with OniSplit 0.9.16.

As for HD Griffin (imported with 0.9.16), the head has exactly 1024 points, and 1832 with cel-shading: clearly overkill, but at least it's below the limit and it doesn't make Oni crash. The source file I'm working with is TRBSgriffin_body_high_EdT.dae from that drop.io folder (why the frack are you guys messing with temporary links and accounts rather than uploading on oni2.net, BTW?)

geyser 19:52, 7 June 2008 (CEST)

Thanks for the update. As to why we are using drop.io, Iritscen doesn't have an oni2.net account so he was using Sendspace to host the files, I suggested using drop.io since it was browser based and could allow others to add files to it. Anyways, these files were temporary in nature.

EdT 21:40, 7 June 2008 (CEST)

Hey, wifi! I only had to drive 20 minutes to get it, too! :-\ Anyway, thanks so much for your work guys (and Neo too, most definitely). I will test this out tonight and report back when I can. Just a couple notes, as FYIs: my working version of HD Griffin has 1887 vertices total (858 in the head). I hope that the FBX-Converter-disconnecting-triangles bug (which I have confirmed on my own machine too) has not added many unnecessary points to the model that you have been working with. Geyser, is that 1024 points that you mention a result of normals being added to the 858? You may not be able to answer that without looking at the file I just uploaded to the drop.io account -- it's the actual .blend file I work with. I probably should have uploaded it a while ago. Well, feel free to open it in your own copy of Blender, export it, etc. I am mainly uploading it now so that a non-disconnected version is available. That's not to malign Ed's version, which does work, after all. It's just that I'm a little confused because my export (using OniSplit 0.9.14 the other week) of Ed's fixed version of HD Griffin had 1814 points in the head, so I don't know how your came to have less, geyser. Are you familiar with the disconnection problem, and do you know how to look for it in whatever .dae file you've been using?

In closing, I will just reassure geyser on two points: assuming I get permission, of course, I fully intend to open an oni2.net account in about a month, to host things properly; secondly, I will in fact be producing a low-detail HD Griffin. I got a little distracted with some other modeling work ^_^, but it will materialize, make no mistake.

--Iritscen 19:14, 9 June 2008 (CEST)

Oni's "points" do not directly correspond to vertices, UVs, or normals, but to combinations thereof. For smooth normals, there is a 1:1 correspondence between vertices and vertex normals, so Oni's points can be seen as unique vertex/UV pairs. Again, there is usually 1 UV per vertex, except at the "seams", where 2 or more UVs can share a vertex. For non-smooth normals, there are 2 or more normals for every vertex that's adjacent to a hard edge, and the "points" are then unique vertex/UV/normal triplets; mostly smooth normals and cleverly designed UV seams are recommended in order to keep the number of Oni "points" low.

The Autodesk converter indeed seems to disconnect the mesh along the hard edges, although in the case of the head some of the disconnectedness is due to your own modeling (new triangles created to fill in gaps are not always connected properly). OniSplit won't care about that disconnectedness anyway, as long as you use the -normals feature, but of course it's better to tidy up new geometry as you go along. I'm not sure if Ed used the -normals tag when creating a TRBS out of your Griffin; either way, the 1814<4457 are essentially a characterization of Autodesk's DAE vs Blender's. As for 1024<1814, remember that -normals didn't minimize the point count properly until 0.9.16.

For your information (or education, I don't know), HERE is the Griffin-like guy from World of Warcraft. You can see the head has only 187 vertices (and could do with less), which is about the double of Oni's Griffin. So, like I told you, it's definitely not about the poly count, but about how you use it: 4-fold subdivision of the original Griffin is plenty enough for good looks, and, erm, vice-versa (über-hi-poly models can be über-crappy).

Like I also told you before, you are welcome to use THIS as a template. This looks like a better use of your time to me, because of the many issues your model still has on a vertex/triangle level (frankly, after the tons of asymmetric operations, the mesh looks more like Mutant Griffin right now). And a lower-detail version is not easy to make, either. There is little chance that the auto-simplified geometry will look good, so you'll have to basically redesign everything anyway.

--geyser 00:20, 10 June 2008 (CEST)

Okay, three things: first, although it seems that OniSplit will now ignore duplicate vertices, it's still quite time-consuming to edit a model where many points need to be merged first. Fortunately, all you have to do in Blender is select all the points in a part, press 'W' to call up the Specials Menu, and choose Remove Doubles. Voila. No more disconnected triangles.

Secondly, I disagree that the WoW guy has enough polygons. You are still stuck in 1999 if you think that a player can't see that kind of jagginess in a character model. Our eyes have adjusted to modern graphics, and that sort of simplicity is no longer acceptable. If you think that model has enough polygons, well, what the heck is point of having an HD model at all? And if you don't see the point of an HD model, then I will just shake my head and go my own way with my work, because I do see the point. That's not to say that I won't produce a lower-res model for Griffin and any others that I HD-ify, just that they won't have 187 vertices in their heads. Not to mention that HD textures such as you are trying to enable for Oni would be completely wasted on such a low-poly model. Finally, you clearly don't know how 3D modeling works if you think it's hard to downscale the polys in an existing high-poly model, and yes, I intend to do it by hand. I've adjusted every vertex myself so far, and I will keep doing so.

Thirdly, what the blam are you talking about? Asymmetric operations? In Griffin's face? I hope that's not what you're saying. Please, geyser, if you really mean that, you must upload an image with the kind of notes that I made on the screenshots of Griffin and Muro, where I pointed out their existing flaws. I simply cannot imagine what you are seeing unless you are due for a new prescription on your glasses. Now, if you're talking about the hair, it's true that it is not perfectly symmetrical. This was intentional on my part, as a matter of fact. When dealing with stylized hair (such as the traditional anime spiky 'do), symmetry actually looks wrong. Hair is supposed to be organic. It's impossible to model it in a way that looks totally natural working with the technology available to us, but at the least, I thought that if Griffin's new hair had spikes added (in line with Lorraine's art), then they oughtn't to look symmetrical because then it looks cheesy. So the idea is that Griffin combs his hair back every day, but it goes back slightly differently on one side than on the other. I don't have the time to check out Konoko's original model at the moment, but I'm pretty sure her spikes are quite asymmetrical too. Not sure if that's what you were talking about or not, but honestly, saying things like "the mesh looks more like Mutant Griffin right now" is just not good for you.

--Iritscen 17:26, 11 June 2008 (CEST)