Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Darkhill on April 04, 2006, 12:06:02 am
-
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
-
Woo, Woo!
Updates are cool.
Nice work mate. :)
-
Augh! The word is "INTERIM." There is no such word as "interm."
-
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:
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?)
-
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.
-
@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 :D
Serious, that would be awesome. Nothing better than the modelview "modelviewer" to edit stuff in !
-
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?
-
darkhill, don't forget to fix the damn memory leak for those who don't have the money for RAM sticks. :p
otherwise, thanks!
oh, and please implement a feature that allows us to view DDS files and any other map form. :)
-
Cobra, is it possible for you to make a request without vulgarity? It is really rude.
Also; Darkhill: Thank you much for this.
-
i call it a damn memory leak because it's annoying and really inhibits the work i sometimes do.
-
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.
-
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.
-
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.
-
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.
-
A Modelview update?
Awesome! :yes: 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. ;)
-
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! :D
-
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.
-
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:
#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. ;)
-
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
-
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.
-
I'm not quite sure why this model was crashing, but it was crashing the other Modelview as well. Tracked down the problem and mostly fixed it. But it still crops up when I try and load in this model with four LODs and a bit over 11,000 polys. It still crashes when trying to load up this 16,000 poly model but then PCS chokes on it too. Though even 100,000 is well within the range of a float. One thing I've noticed is it doesn't calcuate the same radius as PCS does, this also happens to be where the crash is happening.
For them glows I was just going to read the data in and write it back out for the mean time. Never thought of any kind of rendering scheme for it. Might be possible to render the ani for the glow and make it work.
-
The glows are just bitmaps, usually TGA so I doubt they'd work anyway. There's no animation defined for them usually, and I'm honestly not sure that anis even work for glowpoints. Ideally they would be given the same sort of wireframe inidicator that engine glows are, but that's a pipe-dream. I'd just be happy if the data stuck around and wasn't modifiable.
-
Good news :yes:
If you manage to fix the glowpoint-eating-bug and maybe even add a edit box for the ship_radius value, Modelview will be useful again.
Any further features would be the icing on the cake, but awesome nonetheless.
-
Should no longer eat glow point data, can't edit anything at this point but it does read and write it back out. Should support models upto at least 11,000 polys now.
I just randomly set it to 32 glow points and 32 slots in each point. If people want to use more then that I can up it. Download it from the link in the first post if you want to try it out. Would be very helpful to me if you did.
-
@Darkhill: If you want, you can copy me on your current code and I'll have at look at the limit and memory issues. And if you haven't already gotten a DDS loader in there I can easily take care of that as well. If you get back to me before the end of Friday then I can work on it while I'm out of town this weekend, since I won't have much else interesting to entertain me. :)
-
I'll send it your way. It has no problem loading in a cob of a bit over 16,000 polys but when converting it to pof format to display it crashes. Think its writing to memory not in its address space, or something along those lines. I can comment out a couple of pieces and it will import a model with more polys.
-
I'm curious: So far most of our tools have been constrained to inport/export of the cob format. I've been wondering if it would be possible to make an additional import export format type available such as 3ds without a monumental ammount of work or slowing the good momentum that you folks have started here? Just a thought. It's great to see somebody doing something to update this program. Good darts folks!
-
Yes please stick with this DH. When community members step up and give us more options (or revisions) it can only benefit everyone. Thanks for showing initiative! :D
-
I'm curious: So far most of our tools have been constrained to inport/export of the cob format. I've been wondering if it would be possible to make an additional import export format type available such as 3ds without a monumental ammount of work or slowing the good momentum that you folks have started here?
Observant much (http://www.hard-light.net/forums/index.php/topic,26260.0.html)?
-
It should be noted that, while everyone seems to love it out of necessity, the actual 3ds format is a real dog to work with. It takes far longer to fix the nastyness caused by 3ds export in max than it does to set up the conversion heirarchy for a ship, and I can't imagine trying to make that automated. Asking for 3ds support is like asking for Geomod; no one in their right mind wants to code that up.
-
there is a reason why i use DevIL
-
I agree, please do continue working at this :) Modelview is a great tool, and DDS/TGA support would be a great benefit. If you get the time, could you maybe work on the cob2pof code to make it more efficient/work? :)
-
That's a good one, you should put that in your siggy Stratcomm.. :P
-
It should be noted that, while everyone seems to love it out of necessity, the actual 3ds format is a real dog to work with. It takes far longer to fix the nastyness caused by 3ds export in max than it does to set up the conversion heirarchy for a ship, and I can't imagine trying to make that automated. Asking for 3ds support is like asking for Geomod; no one in their right mind wants to code that up.
I'm left wondering myself how many proper (i.e. by developers, from scratch and custom built to fit their game/tool as internal or external devices) use 3ds rather than .max format. I suspect the answer would be very close to none.
-
I was using 3ds as an example. It could just as easily been dxf or obj I used. As usual the question was ignored for the details. The question was: Could support for another format than cob be used without a major problem? The reason I ask is because it would increase the flexibility of the tool for modelers. I see lots of negative commentary about 3ds but little to no information about the actual question.
As a matter of fact I don't care what format might be chosen. I have max 6, and for the most part the recently released plug-in works for me.
-
Should be able to add and delete thrusters at will now.
Giving talyor what I got so far in hopes maybe he can track down crash on import. If he doesn't add in DDS support I'm sure I can figure out whats going on with FS2 code to add it in.
-
Hellbender support for additional formats is one of the scheduled features of PCS2.0
Only POF and COB are on the roadmap for 2.0, however 3ds format is on the roadmap for 2.1 (And is the primary feature of 2.1)
-
YAY Modelview is the best and finally theres someone working on it. excellent work DarkHill
I'd better add this revelation to my ModelView FAQ. (see siggy)
-
Finally got a chance to do some more work.
-Better radius size on import
-Edit the main radius of a ship (but not subobject radii)
-Calcuates mass on import
-Dock points are fully editable now
Probably see what I can get done with paths next.
-
i use Modelview as often as I use PCS2 actually.. however
darkhill send me an instant message - it's probably time we combine our efforts into one tool
-
Perhaps you could rid MODview of one realy nasty bug. This actually may be due to the afore-mentioned memory leak resulting from the perhaps over-zealous limits boost. When I've been working with a model for some time, it gets to a point where MODview is using up too much memory and refuses to save the model I'm working on. Furthermore, upon shutting down the program, I find that the model file has now been chopped in filesize from 1000 KB to perhaps 300 or even 1K and is completely corrupt, meanling a loss of all work on that model. It's one of the main reasons that I still use PCS1 for most of my pof editing.
-
Forgot to say thanks to taylor for finding the bug on importing high poly models. Modelview will import up to a 30,000 poly model but FS2 crashed on trying to load the mission. Didn't really check anything out with it, could have been something wrong with my base model.
Kazan - If PCS had a rendering engine like Modelview then it would be the ultimate model tool. Pretty much the reason I goto Modelview is its much easier to place gunpoints/turrets when you have a textured model that you can move around and not just rotate. Check your PMs.
I know that memory leak is a nasty one. But I don't think it has to do with the up'ed model limits. I used the low poly version of it for a long time and would get slow down after a lot of moving around. Depending on what me and Kazan do I'll try and see if I can find that leak.
-
It's important that I point out that the Modelview crosshair-style points are probably it's greatest advantage (combined with the fact that those points cull correctly), even over moving, because it's not an educated guess where something is getting placed. The display method in PCS 1 was less useful for that because of how it treated points, among other things.
As for the memory leak, I doubt it's caused by bumping limits but it's certainly exacerbated by them. It also seems to happen more in edit mode, almost like it's not freeing the old chunk (or worse, the model) and just adding another instance to memory when it applies something. I haven't taken any kind of look at the source, of course, so I really don't know.
-
Kazan, if you combine efforts I'd prefer if you kept Modelview's interface and your functionality. No offense but you haven't been the best at making things user-friendly, and definately not as much as Modelview :)
And if either of you do continue the upgrade, could you maybe fix Modelview's importer? It seperates all the vertices in the final mesh.
-
Kazan, if you combine efforts I'd prefer if you kept Modelview's interface and your functionality. No offense but you haven't been the best at making things user-friendly, and definately not as much as Modelview :)
And if either of you do continue the upgrade, could you maybe fix Modelview's importer? It seperates all the vertices in the final mesh.
i freely admit my ability to write user friendly interfaces is lacking, possibly has to do with the fact i HATE writing user interfaces.
-
Kazan - If PCS had a rendering engine like Modelview then it would be the ultimate model tool.
you haven't see screenshots of 2.x builds have you? :D
it's not as featurific as modelview yet but it was slated to do most of the same things - then in the post-2.0 roadmap was planned to add some simple geometry editing.
latest source build (done just to take this screenshot)
(http://www.ferrium.org/media/PCS-20060416.jpg)
-
Quite nice! I actually like working on GUI stuff.
-
Looks to be very much an improvement. :yes:
Updated tools are just as important as game engine upgrades, and I'm happy to see it starting to happen. Keep up the good work guys!
-
For the things I've needed to work on recently, there's already more functionality crammed into that screenshot than PCS and Modelview combined. If it saves.
-
What's the "FUEL" used for?
-
Actually, nothing. However, I expect that Kazan planned it to be part of his alternate model format planned for use with Ferrium.
-
What's the "FUEL" used for?
Thrusters.
-
hi,
a question, download the file and unzip it to the install dictionary of the modviewer, and nothing other?
if yes, i got a crash immediately if i want to start the modview.exe.
operationsystem is win2k with sp4 and the last patches.
if you want, i can send you the drwaston log.
Mehrpack
-
Shield importing...
PCS won't pof model, MV does. Model works in game.
Go back and import a shield mesh and upon hitting the check button to apply it causes CTD error and model is corrupted to 0kb.
Just thought I'd throw that out there...
-
won't "POF model"? wtf you mean?
-
Windows 2000 SP4 is what I have been developing it on. Make sure there is nothing else fishy going on.
About the shields, I have not touched any of that code. Sure its not a bad shield to begin with? For me at least Modelview doesn't import shields right when importing a cob. Whereas PCS loads it up just fine. Haven't even looked at that code so I'm not sure if Modelview is expecting the shield to be setup differently then what PCS wants.
-
You may try using PCS to import. If the old shield chunk was valid, PCS won't complain.
-
Kazan, I'm pretty sure 'won't POF model' means 'won't make a .pof file out of the model'.
-
:Giggle: The various messages and symptons have been well documented over the (years).
Sometimes you just have to bite the bullet and use modelview, otherwise you aint gonnna get that model in game.
One thing I have noticed is that using the "High level cob2pof" program is a risky thing as when you try to then edit it with PCS it compains "is this a valid fs2 model?" so at that point you are screwed...
-
Back on topic.
Two questions for Darkhill/Taylor.......
1) Are you going to add glow support and activate path editing?
2) Is the source code available? Perhaps you can give it me/post a link?
OK THREE questions I lied!!!
3) The version on your link compiled 16/04/2006 does not seem to allow high poly models is there a newer version?
:headz:
-
incedently the answer to all of those questions is 'yes' if directed at PCS2.
-
incedently the answer to all of those questions is 'yes' if directed at PCS2.
Actually I'm asking about modelview.
I want the sourcecode to modelview from it modders so modelview dosent have loads of varients creating confusion in the FS community.
I'm thinking about creating a Freespace tool store.
I believe i have enought tools to interest a few people. If anyone wants some let me know.
Tries to attach picture........fails!!!! :mad: :mad:
See attached picture below.
-
I know you were asking about model view, but like I said, incidentally.
wow, segeltuch, FSMM2, wow, these are things I have not seen in years, brings back some memories.
-
wow, segeltuch, FSMM2, wow, these are things I have not seen in years, brings back some memories.
Bobboau have you seen the pof gui tool!!
It might interest you, its written in Blitz Basic very weird!!
-
I don't now, i thought I've used every pof related tool under the sun, put it up somewere I'll take a look at it.
and what is in that BSPGen info.rtf?
-
Bobboau,
I can't attach the POF GUI program as it breaks the 512kB limit (it is 1 meg in size).
Contact me on my e-mail address in my sig and I will e-mail it to you.
The BSPGeninfo.rtf is only some e-mails from a bb about problems getting the the BSPGen utility from :v: no useful data.
-
what sort of problems?
-
Use this site, no limits, quick and easy. lasts 30 days from last activity.
http://upload2.net/
Browse, upload, then copy post link in forum. Done...
-
what sort of problems?
They wont release the tools!!! The mails were from requests in late 1999 so there was still a possiblilty of another game based on Freespace.
We now know that did not happen!!! :( :(
POF GUI is now uploaded to here.....
http://upload2.net/page/download/yApBhwuRkjjJr3Y/pof+gui.exe.html
You will have to wait 50 secs and then download.