[PC] p model simple editor - Kimera (0.97b)

  • Thread starter Thread starter Borde
  • Start date Start date
Status
Not open for further replies.
oh and uh, one more thing, if you're still working on this...the repositioning seems a lot more meant for field models than battle models. it takes several uses of -100 or +100 to have a significant effect...

the brighter/darker thing works well though, as does the resize option (for battle/field conversion).
 
jejeje... yeah, the reposition option hasn't got any use for battle models because they are like 40 times larger than the field models. Actually, the reposition sliders only range from -10 to +10 (yes, it divides the value of the slider by 100) in order to provide values that make sens while working with field models. Maybe I should make this based on the size of the object. Well, maybe next time.
In order to avoid overflow problems, I think it would be enough to reduce the models. But maybe I'm worng.
Oh, and there is actually a problematic bug when saving. The normals aren't well calculated and the group 1 polgons should allways be white . I should do a quick release soon in order to fix it.
 
Well, here is it. It took me longer than I expected, but here you have the new version. The most important feature added is the direct polygon painting.
By the way chocomog, are the files edited with my program still usable as battle models?
 
Oh, it's easy. It can take you about 5 minutes to do it:
First open the file which defines the model field skeleton (HRC file, in this case aaaa.hrc). Open it with notepad or wordapad or whatever you want, it's a text file. Here you will see a list of "bones". Bones are defined by their 2 ends (the joints they connect), lenght and a list of RSD files (preceded by the total number of files in the list). If you want to do an SD character or something like that, you should divide the lenght of the bones by 1.5 or so.
Now, look for the RSD files that define the limbs and torso. This files are also plain text and they point directly to the P files. You have to scale those P files to 75% or so.
And that's all. :-P
Anyway, I'm working on a little program to make SD characters automatically (I just love the SD style).
 
Well, here is it. It took me longer than I expected, but here you have the new version. The most important feature added is the direct polygon painting.
By the way chocomog, are the files edited with my program still usable as battle models?
Click to expand...

well, i get a runtime error 13 - type mismatch when i try to save after editing, so no, they're not exactly usable >_>

the overflow error on fat/thin still occurs for me.
 
WHAT?! Type mismatch? Man, there must be a serious bug in my code. Could you detail how did you trigger that error?
 
sure...open'ed hiam, reposition/rotate/resize something, try to save
 
Now I see why there is a type mismatch error. Well, actually it's a problem with the error handling routine (stupid visual basic...). Anyway, I've been playing arount a bit with the hiam file and it worked right when I saved it. However, I've been changing the code recently and maybe that solved the problem. Well, anyway, expect a new release soon.
 
Version 0.5 it's out.
Now you can insert polygons (specially useful for closing objects after removing polys).
 
You are right chocomog. I thought I had fixed it, but I didin't. Oh well, I'll do it for the next release.
There are also 2 more bugs that I must solve:
 -Adding polygons on a multi-group p-file (any textured file) will cause the file corruption. I've solved this problem already so the new version will be fine.
 -The vertices order on poligons is wrong sometimes. That's a bad thing because the game thinks that they are facing inside the screen (and thus, won't draw them). I don't really understand how must the vertices be sorted, but I think I can solve it easily.

Sorry for the lack of updates, but I'm "bussy" testing my ViperGC :-P.
 
FF7 uses back face culling, which is pretty much the simplest way to optimise polygon drawing. Basically, you look at the polygon, and see whether (from your current viewpoint) the vertices are in a clockwise or anticlockwise order. Then you know whether it's facing you or not, and you don't bother drawing polygons facing the other way.

Google for it if you need any of the maths to help work out which order you need to create your vertices in...
 
Thanks for your advice Fice. Yeah, I've read the way that algorithm works, but I didn't undesrtood it very well. Now I think I know where my code was wrong.
There you have a new release. Simply a bug-fix release, sorry. No new features added. I'll try to do something interesting next week.
 
Status
Not open for further replies.
Back
Top