[Darkhill]

Seeing how you can't edit eye points in Modelview and at least for me you can't edit all of them in POF CS, I tried to do something about it.  You should be able to edit all the fields and the changes stick.  Tried this with models that have just about all the extra pieces and they still load.  If you all would like to give it a shot and see if you can break it that would be great.  This isn't the high ploy version that is floating around so make sure you backup your current exe.  If whoever updated it for high poly told me what they did I could fix this one up to handle them too.

Another thing that annoyed me greatly was after importing a cob it goes back to a default folder path.  Now when you goto save it will start you off in the folder you imported the cob from.

In no way am I trying to replace or do anything else with PCS 2.0.  These are a couple of things that have annoyed me since day one and wanted to have some kind of interm fix while PCS 2.0 is finished.

http://ia.emperorshammer.net/updates/modviw32.zip

[Grug]

Woo, Woo!
Updates are cool.
Nice work mate.

[CaptJosh]

Augh! The word is "INTERIM." There is no such word as "interm."

[Vasudan Admiral]

If whoever updated it for high poly told me what they did I could fix this one up to handle them too.

Heh, that'd be me, but with no current coding knowledge, all I did was find the relevant #define limits on polygon counts, verticie counts and the rest in 'Fs-extra.h', and set them really really high. (it's probably the cause of the memory leaks people complain about actually )

Also, I allowed much larger textures to be used by editng this bit in 'MODVIEW32Doc.cpp', Line 1060:

Code: [Select]

if(xreal*yreal>4096*4096)
{
m_FS_BitmapData.pic[i].valid=0;
m_Textures[m_TexturesNum].Valid=FALSE;
m_Textures[m_TexturesNum].Error="PCX Texture too big (>16777216 pixels)";
break;
}
If you could do a propper implementation of the high limits, allowing for models like Omni's Battlestar and the rest, that'd be awesome.
(actually, might it be possible to get it to load DDS textures as well?)

[Goober5000]

Super!  The community has wanted ModelView development for quite some time now.

If you're willing, I think everyone would love it if you continued to work on it.  Kazan has vanished into the Everquest singularity, so it appears that PCS 2.0 will go the way of Ferrium.

[Starman01]

@Darkhill : When you really improve modelview, and maybe even add the missing features to modelview (thrusters, dockpoints, eyepoints, etc). I will personally worship you, promised

Serious, that would be awesome. Nothing better than the modelview "modelviewer" to edit stuff in !

[Darkhill]

You sure you didn't change anything else?  I think I tried those and like one named MAX_POLY (or something) and now Modelview crashes trying to import models that I'm pretty sure the current high poly version imports.

Looks like it should be simple enough to make it create thrusters/glow points since right now it has no problem editing an exisiting thruster.  Same goes with the AI docking path, game already shows them should be trivial to add some edit boxes to change the values.  I would like to see a point and click path editor.  That one I'm not sure about, if I get to that point it will probably be a edit box affair like PCS is now.

Starman01, eye points do work now.  Thats why I made the post to see if people wanted to try it and see if it works for them.

Would anybody know how Kazan calcuates the mass of a cob when he imports?

[Cobra]

darkhill, don't forget to fix the damn memory leak for those who don't have the money for RAM sticks.

otherwise, thanks!

oh, and please implement a feature that allows us to view DDS files and any other map form.

[Taristin]

Cobra, is it possible for you to make a request without vulgarity? It is really rude.


Also; Darkhill: Thank you much for this.

[Cobra]

i call it a damn memory leak because it's annoying and really inhibits the work i sometimes do.

[Taristin]

i call it a damn memory leak because it's annoying and really inhibits the work i sometimes do.

No matter. Learn to express yourself in a non-vulgar manner. Even when you're praising people you sound insulting.

[StratComm]

I'll admit I haven't had a chance to test this yet, but has it been fixed to not delete the GLOW chunk yet?  That's the reason I all but stopped using modelview in the first place.

[Darkhill]

Try running it in debug build, it will quickly eat up 300-400 megs of memory.

What do you mean its deleting the glow chunk?  I added glow lights to a model when testing the eye points and they were still there upon program exit and reload.

-Edit-

You are talking about the glow chunk tab in PCS.  Between a hex editor, PCS, and FS2 code I can probably figure out whats going on with it.

Have to beat back the evil of MFC on this.  FRED2 has nothing on Modelview.

[StratComm]

The GLOW chunk is the POF data structure that handles SCP glowpoints, and are not the same as the light points on retail models (which are in the header).  It's not a retail structure, and old Modelview would not retain it if the model was loaded and then resaved.  From my (albeit limited - please correct me if I'm offbase here) understanding of the way Modelview works, it loads the entire POF file and then overwrites the old file with the one modified in memory when you save.  The problem was that it was ignoring the GLOW chunk before, the chunk wouldn't be in the memory image, and so would cause you to lose that data when you saved the model.  That's why I asked; as I said, I haven't had a chance to try it on a model with glowpoints.

Looks like it needs its vertex limit bumped too, as 5000 isn't nearly enough for a proper HTL model.  Give it at least an extra 0.

EDIT: looks like you figured out what I meant   Glow's pretty basic stuff AFAIK, and what you see in PCS should just be what's there, unlike just about everything else PCS related ("I don't know what this does so no one can change it, even if it is important" ~ Kazan) since it's something implimented from the standard where everything was known.

[DaBrain]

A Modelview update?

Awesome!  I'm just trying to get better at this converting stuff. Modelview is still my prefered software. If you get a model loaded (yeah it has limitations...) it's the easiest software you can use for converting IMO.

It just lacks a few features... yet.

[Getter Robo G]

A little competition is good for the comunity. When MV messes up on me a lot of times it corrupts teh model to 9kb's and ruins it. any way of stoppign that so it simply fails and doesn't auto save? no biggie though, higher poly and vetice limits would be nice.  Even with HTL MV occasionally I still get (boundinh box too big)

Go Dakhill go!

[ToecrusherHammerjaw]

Awesome!  My tool of life, ModelView32, finally updated! Thanks Darkhill!  Also, I second the dds support idea.  That is the only thing keeping me from viewing just about everything the way I want to.

[Vasudan Admiral]

Well, I don't recall editing anything beyond that chunk of code, so I'd assume it has to be something in here that makes it work:

Code: [Select]

#define MAX_FS_TEXTURE     60
#define MAX_FS_SOBJ        180
#define MAX_FS_THRUSTERS 16
#define MAX_FS_THRUSTERS_GLOWS 16
#define MAX_FS_SHIELDFACES 4800
#define MAX_FS_SHIELDVERTICES 2400
#define MAX_FS_SUBMODEL_POINTS 8000
#define MAX_FS_POLYGONS 80000
#define MAX_FS_VERTICES 100000
#define MAX_FS_NORMALS 80000
#define MAX_FS_CROSSSECTIONS 64
#define MAX_FS_LIGHTS 128
#define MAX_FS_BBOXS 40000
#define MAX_FS_FIRING_POINTS 64
#define MAX_FS_DOCKS 32
#define MAX_FS_SPLINE_PATHS 256
#define MAX_FS_DOCK_POINTS 256
#define MAX_FS_TURRETS_BANKS 128
#define MAX_FS_REALGUNS_SLOTS 128
#define MAX_FS_FILESINVP 4000
#define MAX_FS_POFFILESINVP 200
#define MAX_FS_SUBSYSTEMS 1024
The majority of those limits are probably bumped way too high, which I'd imagine causes the memory leak.

[Kazan]

Super!  The community has wanted ModelView development for quite some time now.

If you're willing, I think everyone would love it if you continued to work on it.  Kazan has vanished into the Everquest singularity, so it appears that PCS 2.0 will go the way of Ferrium.

so long as I remain monkeyed probably - without the ability to discuss OT things my attention span is quickly taken away by eqforums, bigsoccer forums, etc

[StratComm]

Well, I don't recall editing anything beyond that chunk of code, so I'd assume it has to be something in here that makes it work:
< code>

The majority of those limits are probably bumped way too high, which I'd imagine causes the memory leak.

#define MAX_FS_CROSSSECTIONS 64

Could that be it?  The rest of it isn't really geometry related and so shouldn't affect ships like the HTL Fenris or Orion.  I'd imagine TBP would love you if you could bump FILES_IN_VP a bit too, though I don't know the consequences of doing that.

EDIT: Also, the memory leak isn't caused by any of the bumps, just exacerbated by them.  You don't notice a leak for the length of time people use modelview when you're using up memory by the Kbyte, if that fast, but when the limits are set sky-high then things get more problematic.  Of course, as a coder, you know this.  I suspect the leak has to do with (re)drawing the render window, since the leak becomes a problem fastest when I'm dragginig a ship around to edit it.  The other time it ginds to a halt is when I'm changing something that affects the render state (like moving a subsystem point, or switching between display modes) so it might be related.  Of course, there's a myriad of things going on back there that I can't see and don't follow well enough to really know.

EDIT2: You can probably solve the glow problem, at least temporarily, by reading in everything after the last retail data chunk to a buffer and then writing that buffer on save after you've written the POF, before you close the file.  That'd be at least a stop-gap solution to the problem, if you don't want to impliment another drawing option for the window.