Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on December 28, 2004, 11:30:28 pm
-
with the comeing of PCS 2 and it getting mentioned in another thread prompting me to think about it I'm starting up a discusion on the interface, this being (IMHO) PCS 1's biggest shortcomeing.
first, I think for everything there should be a common list element selector type (it would be nice if some sort of templated controle could be made) I am attaching a picture of a slightly altered Aurora selection controle, it alows you to select an item in a list, displays the name and number of the item currently selected, allows you to create a new item, delete an old one, or (my personal favorite and a _MAJOR_ time saver) copy an exsisting item. other jobs that could be placed here would be incerting before/after the current item, moveing the current item to a position on the list, and 'import from other pof'.
/*programming note: this means that every data type that has an array in it will likely need to be derived from some sort of item_list object to make the programming of this sort of controle easier, this would also make things like ray picking and all other common 'do this to this item' jobs precisely one hell of a lot easier as well*/
if it could be posable an undo/redo option would be magical, though this would probly require a string of pof objects and might not be the greatest memory saver.
it would be nice if PCS 2 could have a much more graphical editing ability. how I think the PCS2 graphical editor should work would be like this.
in one of the upper corners of the render window (or near one of the upper corners outside of it) there will be an axis selection box it'll have x,y,and z, there will also be a movement type box that will consist of global, local, and camera these refer to the three major coordanant systems and will alow easy movement of any item (it's also very similar to how truespace works)
what ever item you have selected when you move the mouse with the left button down and the controle key pressed it would move along the two axes you have selected, if you have the right button down insted it will move along the one axis you don't have selected, in global space it will move relitive to the global center of the whole model, if you select local it will move relitive to the orientation of the currently selected item (along a plane normal to to it, this won't be aplicable to all items), and lastly camera will move along your screen (or into it with the right button).
you should be able to use a ray picking system to select items (yes Kaz I am also working on this with you, I know how to do this, it's actualy _quite_ easy) from the render window, if hotkeys are assigned for new, copy, and delete, it should be posable to fully edit a model from only the render window other than maybe going back to the main window to change data types.
selection of what data types are veiwable should be available via the view menue, though the currently selected data type should always be rendered.
user options on the color of each displayed data type for unselected-not on list, unselected-on list (items that are not selected but on the same list as the selected item) and, selected items
there should be a full text mode, (this would be similar to PCS without the render window), mixed mode, (this would be similar to model view with a render window comeing off the side of the text based editor), and full graphics mode ((posably with full screen options) were no texted based editor would be seen at all (allowing maximum veiwability of the model))
-
Sounds Ok to me. But I'd rather not have a UV editter in it. Perhaps it's just me, but I prefer to do my mapping in Max.
-
so if after hours and hours of work your just about done then you see one small poly that you mis-mapped "oh no! now I have to open it up in *incert modeling environment of choice* load the model open it'uv editor fix the small error (four seconds of work) save it recompile import the data from the old model and save" or open PCS2's u editor and fix it there, also useful for if you want to change something in the map but can't be assed to recompile, or if you lose the origonal file. it's a time saver.
-
Let me sit with paint a few minutes and see what i can come up with. I like to think that I can design decent user-friendly GUIs.
*updated*
(http://www.geocities.com/lorzon1/pcs2.bmp)
-
*salivats at the thought of PCS2 and its many possibilities*
I would request that is support multiple map formats (pcx, jpg, tga, dds), perhaps allow glow and/or spec maps to be viewed as well, and be a little more intelligent when trying to find the maps. In PCS, when I run it from WinXP (off the Win98SE E:\ partition) it can't find the textures, but Modview can (if there in the FS VPs). However, if I reboot into Win98SE (which then thinks its C:\), PCS can find the textures no problem. Furthermore, could you ensure that if no model is loaded when the program is started, that the "save file" option is greyed out. I recently lost alot of work on a model when I mistakenly chose this option when trying to open a model, and ended up replacing a 2.2MB model with a 160 byte file of nothing. All of that said, I do find PCS more stable and feature-filled than ModView, which is prone to crashing alot on me when I try to save stuff.
Later!
[Edit]
Oops! I appologize for including this, as I now recall this is for INTERFACE DISCUSSION ONLY, and some of my requests delve into other areas.
[/Edit]
-
Originally posted by Raa
Sounds Ok to me. But I'd rather not have a UV editter in it. Perhaps it's just me, but I prefer to do my mapping in Max.
Originally posted by Bobboau
so if after hours and hours of work your just about done then you see one small poly that you mis-mapped "oh no! now I have to open it up in *incert modeling environment of choice* load the model open it'uv editor fix the small error (four seconds of work) save it recompile import the data from the old model and save" or open PCS2's u editor and fix it there, also useful for if you want to change something in the map but can't be assed to recompile, or if you lose the origonal file. it's a time saver.
With the 3ds->pof plugin you don't need to use PCS atall (unless there's an MOI editor added....), so I'm not sure what this here arguement is even about.
-
So long as there is a decent tut as per "learn to use PCS" I think any interface would be fine. So long as it is logical ofcourse
-
Originally posted by aldo_14
With the 3ds->pof plugin you don't need to use PCS atall (unless there's an MOI editor added....), so I'm not sure what this here arguement is even about.
Well, that, and the fact that PCS had a handy 'import pof data from another mesh' feature, which I'd use.
I'd finish the mesh currently, go back, fix the problem I had originally, convert it again, and then import the remaining data back into the mesh. Voila.
-
But what I mean is, your max scene should already have all the pof data in it via your dummy objects, etc.
-
generally if you're going to start these discussions make sure i'm where i can participate in them
i've posting from a 56K modem at my inlaws - i should be back in iowa tommorow night if all goes well -- by then i'll gave a screenshot to feed you hungry dogs :D
-
RE: from VPCS2 thread
Originally posted by Bobboau
"UV editor"
this BTW is what utterly killed the last version of Aurora :)
?????
we need to have a talk about the interface of PCS2 sometime.
Once I get back to iowa
oh and is it too late in the game to ask that it might be multi-pof (ie load up multable pofs, edit and move data between them)
no... but lemme ask: what is the point (infact loading multple files remains trivial at this point - since i haven't started writing any of the editor panels)
and the idea is to be able to recompile a model (it would have to if it was going to edit geometry) right?
it's internal editing format is not pof, unlike PCS1 - it's internal format is PMF (PCS Model Format) - when you select and Open/Save of a different file type it converts-on-demand
i will keep it coded in an inspecific manner so that if you convince me to have multiple file support it'll remain trivial to implement
so when you "Save as 'something.pof'" it runs the conversion right then and there, same thing with "Open 'x.cob'" it runs the conversion right then and there (which means the cob->pof autodata features are becoming cob->PMF features)
so saving in a totaly new POF format wouldn't be a prolbem.
supporting new formats is merely a task of writing another "PCS_Model::LoadFrom[type](std::string &filename"/"PCS_Model::SaveTo[type](std::string &filename" pair
This is probably the last time im going to be on the forums today
-
Kazan, could you please add support for Milkshape 3D files?
-
Originally posted by aldo_14
But what I mean is, your max scene should already have all the pof data in it via your dummy objects, etc.
Yes, but the damned plugin doesn't work all that well. I have a 20% success rate with it. And that's optimistic.
-
wishlist:
one feature id like is automatic cooranate scaling. so that i can imput cooranants directly from the modeling program and have them automaticly scaled depending on the conversion scaling factor. maybe something that compensates for truspace's screwy x,y,z order.
i like the spredsheet style data entry idea id like to be able to drag drop cornanants so i could easily convert a primary weapon points to secondary weapon points, chane the order of gunpoints, or convert engine points to glow points, ect. a left click drag and drop would move a set of coords while a right click dragdrop woud copy.
a wysiwyg turret debuger. something that lets you select through the turrets, and test their ability to elevate and rotate, so that you can make sure that the right parts are moving in the right way.
a wysiwyg animation script editor for future support of bobs wip animation code. so that you can set up the animation and export the proper table entries for the animation.
idealy id perfer a one click you done interface (like frelancer's model converter) where all points in the model are autogenerated on compile based on named objects (polygonal or otherwise) in the original unconverted model file. relying on the modeling program to enter all model information. this would make interim model versions really easy. a model gets converted many times before it can be considered done. and the option to set everything in the model program would save modders alot of time.
-
I hate to be all efficiency-oriented and all, but seriously: why not just ask Styxx for the code to his MAX2POF converter, fix the known bugs, and continue enhancing it until it reaches the stage where you can export a 100% usable POF directly from MAX, including all the bells and whistles?
Or, since there are obvious advantages to having a seperate POF editor (eg. for Lightwave users), ask Heiko Hermann to open up MODELVIEW32's source code - that has amazing potential to be all you'd ever need in a POF editor, especially since the graphical side of it is implemented and familiar to everyone.
And if neither of those options will work, then I suggest modeling the interface off a familiar example to nearly everyone - your bog-standard email client, where each "message" is actually a POF setting that can be modified, message folders are categories of settings, and the "Message Preview Pane" could be the live 3d view of the model.
-
Originally posted by Sandwich
Or, since there are obvious advantages to having a seperate POF editor (eg. for Lightwave users), ask Heiko Hermann to open up MODELVIEW32's source code - that has amazing potential to be all you'd ever need in a POF editor, especially since the graphical side of it is implemented and familiar to everyone.
He has released the ModelView source code. But everybody wants to develop his own tool. :p
ModelView only needs one or two more things done to it and it'll be a fully-featured POF editor. It also shouldn't be a large step to add in the auto-pathing, etc.
Heck, I might try it myself one of these days. :nervous:
-
mmm wasn't it just a...plugin? I mean, designed to be used inside max.
But yes, I think you guys should spend some time in adding support for some formats, like lwo or 3ds, althought you aren't confident with those file specifics.
I really think that it'd be the best way to gain some fresh meat....
Persona wishlist (sorry but I'm very shorttime):
shadings: I'd like pcs-2 to be able to use smoothshadings too, and I'd like someone to fix the "faceted" problem happening when using autofacet and in game specular effects. Don't know if it has been fixed recently but I know that it wasn't happening with Styxx's converter.
hierachy editor: ability to edit the hierachy (at the cost of reconverting to pof). This could also mean to import external models inside an existing pof, and, why not, to move/rotate them.
This could be useful for adding turretts or for those who don't use 3ds or TS and don't want to: you could save to 3ds or cob, convert to pof without all the autogen features, set the hierachy inside the pof editor.
-
You know what would be a great format? .OBJ. It's pretty standard, I think.
-
don't ask for new file formats until im done bringing PCS2 up to the same capabilities of PCS1
*grumbles about not being able to put buttons into cells on a grid*
-
Must haves for upcoming PCS2:
1) All importing options that was in the last release of PCS.
2) Aurora's auto path option.
3) Model Scale (measured in meters like in modview32)
4) Model rendering screen in all formats that FS2_open supports
5) In render show all. Such as thrusters glow points, etc. This will help with modellers getting the effects, and details right on the model more effienctly.
Wish list:
1) An error box, so that if there is a model fault the modeller can locate and correct a bit faster.
2) An object remover/importer/ hierarchy adjusting tool. This option will help modellers like myself who are constantly upgrading models to keep up with the new SCP features.
I do not mind redoing a whole model if there is a mess up in the mesh, but these are things that may help in the long run! Thanx in advance guys, and keep up the good work! Looking forward to seeing what you guys create! Good luck!
-
Originally posted by stithe2000
Must haves for upcoming PCS2:
1) All importing options that was in the last release of PCS.
All editors will have data importing, if I don't code it bobboau will once i upload PCS2 to CVS tommorow when i get back to iowa
2) Aurora's auto path option.
Bobboau will have to describe this to me, and possibly code it
3) Model Scale (measured in meters like in modview32
that's trivial
4) Model rendering screen in all formats that FS2_open supports
what do you mean? textured, flat, wireframe? or do you mean GFX features? that would be bobboau's job.. but he's going to have to learn openGL
5) In render show all. Such as thrusters glow points, etc. This will help with modellers getting the effects, and details right on the model more effienctly.
the renderer was incompete in PCS1 - all editors will display their data in PCS2 - it will be context based
but it would be fairy simple to add a toggle for "context" or "all" of such details (i'd NEVER turn on "all" - too cluttered)
Wish list:
1) An error box, so that if there is a model fault the modeller can locate and correct a bit faster.
one of the features of the editor will be "constraints checking" - which means ensuring that no two polygons have a duplicate centroid, and that all polygons have at most 20 points - the internal model editing features should be capable of resolving these errors with user interaction, or automatically
2) An object remover/importer/ hierarchy adjusting tool. This option will help modellers like myself who are constantly upgrading models to keep up with the new SCP features.
it shouldn't be difficult to allow you to copy an entire SOBJ from one model to another, manual and tree-based hierarchy editing shouldn't be difficult either - you'll also be able to edit the detail levels, debris lists, and splits
I do not mind redoing a whole model if there is a mess up in the mesh, but these are things that may help in the long run! Thanx in advance guys, and keep up the good work! Looking forward to seeing what you guys create! Good luck!
thank you
==============================================
Ok, let me write a short thing on how things are working here. I have already designed and implemented PCS Model Format (PMF) which all editing is done in. This makes the internal data game inspecific so that in the future it can support both FS2 and Ferrium, also it makes it easier to write support for new model formats - you only have to translate from TypeX to PMF, which doesn't involve a BSP split. Translating most formats to PMF should be considered trivial (tedious) at worst. The only time that the BSP enters into it is parsing the BSP from a POF to load it into a PMF slot, and generating BSP (on save) when saving to a POF.
PCS2 will support up to 10 simulatenously loaded models - switching between working with models via a radio-group menu. Copy+Paste support will be replaing "import from pof" so you'd just have to select File B, what you're copying, copy, select File A, and paste.
Gun/Missile hardpoint and turret editing are each in one menu - you just create turrets, they're one list and you specify type (gun/missile) when saved to pof it puts the appropriate ones into the appropriate lists. (in order found)
The GUI that i have already begun to implement is designed to look vaguly like ModelView - it will have a large segment of the window dedicated to render - then controls will be laid out along the right hand side. Editors will be spreadsheet like, and each is tabbed between via a radio group in the toolbar (which i need graphics for), i was hoping to inline a little bit more - such as putting the "Add new" button onto the next row in the spreadsheet, but as far as I can tell wxGrid doesn't support having a button on it - i will see what i can do and may be able to possibly implement ths behavior myself (which I will be happy about)
Coding this is wxWidgets is anything but trivial - which means in win32 code it ould be a nightmare!
im going to bed soon, i'll be on the road at not long after 6am tommorow - I have to go from Green Bank, WV to Ames, IA - hopefully i'll be posting again by this time tommorow night.
-
Sounds good. So long as it works, and works well, is all that matters.
-
one thing that I think would be easy but more so if mentioned early would be batch conversion, selecting more than one model of format X and converting them to format Y, particularly if this could be done via a comand line (so if I come up with a new model format I can quick convert everything, and others can do the same once I've finalised the new format)
-
autopathing. and the auto orient from the docking in Aurora. Other than that, I'm good to go.
-
First off thanx for the feedback.... Yes a scaling system is a bit trivial, but for a modeller like myself who works on models like the B5 station... It helps! At least make it a selectable option...
As for the rendering... Any and all options, but textured would be very much appreciated by all! Again.. Thanx in advance for your efforts!
-
One question before I forget... Will your PCS2 render window render the glass feature that has just recently being added to most models being created or modified? If not, no biggy! thx
-
Why should it? If the texture is done right it shouldn't matter.
-
It is one of those nice to have things, but not needed....
-
Originally posted by Goober5000
He has released the ModelView source code. But everybody wants to develop his own tool. :p
ModelView only needs one or two more things done to it and it'll be a fully-featured POF editor. It also shouldn't be a large step to add in the auto-pathing, etc.
Heck, I might try it myself one of these days. :nervous:
PCS / MAX2POF as convertor, Modelview as the WYSIWYG editor/tweaker would be ideal IMO.
My first thought would be that it'd be easier to leverage the existing mode view code rather than to (effectively) re-write it.
Originally posted by Raa
Yes, but the damned plugin doesn't work all that well. I have a 20% success rate with it. And that's optimistic.
?
Odd; the only major failures I've had have really been my fault (detail objects with 0x instead of x, unlinked object).... although I haven't made paths/dps or glowpoints yet
-
Originally posted by aldo_14
?
Odd; the only major failures I've had have really been my fault (detail objects with 0x instead of x, unlinked object).... although I haven't made paths/dps or glowpoints yet
Well, I'm using max6, which isn't what either you, or styxx have AFAIK. But even when named exactly the same, including case, and hierarchy set up correctly, the plugin crashes.
Hell, it crashes on a single object (LOD0) only conversion.. :doubt:
-
just dont remove the conversion scaling factor option :D
-
Threre should be a standard conversion size for the model, and then the size is adjusted in the program... That will allow for complete detail modelling... Especially if you can import subobjects... You can piece together your model carefully, and right the first time around with these options/ features. However, it is to the descision for the creators to make for PCS2.... We'll just have to wait and see... Meanwhile, I'll just cross my fingers!
-
you could always set it up to convert the scale on save as pof, before bsp is calculated, rather than on file open. that way you can enter all your coords directly from the modeling program. there would need to be an exception created for opening a pof for a minor adjustment, to force the save conversion factor to 1. so that you dont scale something thats already the size you need it to be (anti moron feature).
id perfer autogen support for everything though.
-
Originally posted by stithe2000
Yes a scaling system is a bit trivial,
i meant that in terms of how difficult it would be to code :P
-
very pre pre alpha
-
YES window.init();
Well, i'l see how this turns out...
-
ok this is my idea currently for the overall interface
all you'd need from the tree is a pointer to the currently selected object, if all data types are derived from the same class then I think this can be done easily enough.
both dividers between the three windows would be fully resiable, and scrol bars would popup when needed.
you'd be able to move items around within there own data types via drag and drop (at least for submodels)
and that second copy button would be an "import from other file" button.
I wan't to know if pepole even like this format though, I have a feeling it's going to be a hard sell to Kazan and I won't even bother if nobody likes it.
-
forgot the dman thing...
-
as you can see the editor pane only has the data to the specific item you have selected, so if you have a point within a bank it has just the data from that point, if you select the entier bank it will have just the editable properties for the bank, but none of the childeren.
-
Originally posted by Kazan
i meant that in terms of how difficult it would be to code :P
Oh! OK! lol! Disregard my last then! lol!
-
Looking pretty good so far! (As I salivate in anticipation!)
-
hm..I like this tree approach, better then a dozen tabs. :yes:
-
tree approach = coding nightmare
i don't know why bobboau posted it after i had idea.veto();
-
I don't like the tree idea. I'm too used to drop down menues to want to change now. :p
-
could you give me a link to WX's tree controle so I can see for myself.
-
http://wxwidgets.org/manuals/2.4.2/wx399.htm#wxtreectrl
you can peek in the pcs2 source to see one being used
-
well just a quick looking at it, it doesn't look too bad just that you'd have to plan everything ahead (and you've already started with a diferent method so I guess that would be it)
-
erg vpcs2 source i meant
-
i kinda like bob's tree. so long as there arent no rediculous restrictions. if i want to be able to take a turret normal and make a glowpoint out of it i should be able to. a dragdrop feature would be nice. with gun/missile points id like to be able to rearranger them fairly easy.
-
it would prbly be doable to have anything that was a vector be drag/dropable into any other vetor object, I don't know right now I'm haveing the devils time trying to get a damned WX progect setup so I can play about with it a little, I'm going to have to learn a UI sooner or later.
-
ok, godamned that was harder than it should have been, future reference for me
settings->c/c++->code generation->run-time library = debug miltithreadded DLL
additional libs = wxmswd.lib comctl32.lib wsock32.lib ws2_32.lib Rpcrt4.lib kernel32.lib user32.lib
-
Just a thought guys... I have seen and heard a lot of people go both ways bout tree format, and tab... Would it be possible to have a display format option (tab or tree display) to satisfiy all or no? I will be happy with what ever you both finally create, but on the same note I am curious... By the way... Happy new year guys!
-
bobboau: release setup->optizations->inline function expansion OFF
-
stithe2000: basically it requires ten times the code to allow both - since the three takes 9 times the code of my way
-
Gotcha! thx!
-
yeah, if I somehow managed to convince him to use the tree there is no way i would even think about asking him to try doing both, ten times as much is a very conservitive estimate of how nightmareish that would be.
I would like to ask that the POF (or model or whatever you want to call it) class is made to be easily portable to another GUI should I get the balls to try to code my idea so. I would think that haveing every array derived from a base class that had all the generic add/copy/delete functions prototyped would be a good idea in any event.
-
Erg, ok, I must be missing something here - what's the problem with doing the tree at all? :wtf:
You can determine the type of data by the icon, you could even have multiple icons that are identical if you didn't feel like making more than a couple.
Then you know what to do with the pointer, what dialog to display when it's clicked. Handling the select message shouldn't be much worse than handling the one from a bunch of tabs.
To display the stuff, all you need is one update function - unless you don't want it to reset every time something is added. In that case you'd need an add function that would take the pointer to the new type, the parent item's pointer, and then the icon to show for it. Then you run through the tree, looking for an item with the same pointer as the parent, and add the item that's being added as its child.
A delete function is also easy, figure out what item's selected, try to delete the item using a standardized delete() function, and then call wxTreeCtrl:: Delete().
It's somewhat confusing/complex but not "nightmarish".
-
WMCoolmon: have you ever written a tree ctrl?
PS the data isn't stored in the GUI - i _NEVER_ use GUIs for data storage, GUIs are presentation only
Bobboau: the internal format is PMF, it will also save "projects" to PMF binaries
-
it would be nice if we can display trees from multiple models, that way it somone wanted to copy a turret from an ursa and put it on a herc they could, and with only a couple dragdrop events.
-
*Sighs* i don't know why we're still discussing the damn tree -- i had idea.veto()'ed it before bobboau even posted it here (We had talked on ICQ)
i've already started writing the other control mechanism anyway! I started writing the Toolbar radio group selector before I even got back from West Virginia
-
yeah, the tree is my thing, if it ever gets done it'll be via an allternate gui that I write.
-
Originally posted by Kazan
WMCoolmon: have you ever written a tree ctrl?
PS the data isn't stored in the GUI - i _NEVER_ use GUIs for data storage, GUIs are presentation only
:doubt: Yes, in fact I used the one I wrote as a model for what I said. While GUIs might not be used for data storage, you can in fact do what I said; you could also make the data portions of the tree items point to a struct containing an int with the type of data, and a union with pointers to the data itself(Assuming you didn't derive anything). That would be more complex though as you'd have to allocate and deallocate the memory for those additional structs.
And while you may have vetoed it, it just seems flat out a better way to do it from the usability side of things, and worth the extra coding time.
-
i really dont care how the data is displayed, i just want to be able to move like data types with a simple dragdrop event. but overall i think i like the tree style interface over a tab style. tab style you can only really look at one chunk at any given time. with the tree you could look at multiple objects from multiple models without the trouble of switching between tabs.
-
erm sort of, you'd be able to move to a specific item a lot faster but you'd still only have one item at a time, and your scope would be a lot narrower than with the traditional tab interface (ie you'd only be able to do one thruster point not the whole thruster, this might get a bit confuseing in data types that have a lot of data in both the child items and the perent items like paths, but it would also save a lot more on space)
-
will it have full autogen support?
-
yes regardless of the overall interface it will have auto-gen and all the snazzy things I made for aurora.
-
Originally posted by Bobboau
(ie you'd only be able to do one thruster point not the whole thruster,
and what exactly is forcing it to be that way?
nothing
-------------
i was just thinking about it and im going to reverse the idea.veto() on the tree ctrl
it would make things a lot easier when it comes to copy+paste
-
i use autogen on everything it can be used on, just wich you could autogen everything.
-
:D yay!
-
there's nothing forceing it to be that way it's just the way I was planning on it workingyou don't realy need access to the parent data while you are editing the children, becase it's just a quick click to get access to the parrent data. I supose it's more of a matter of taste, I think it would be a bit cleaner if it only displayed the data of the element you were editing, not the parent data
-
Bob! Study how to get glow and shine mapping in OGL! Damnit! :D
-
bobboau: they way you stated it implied inability to select the entire object
-
well I was corecting a misconception that you'd be selecting multable objects at the same time.
-
just wondering how this was coming along. I am very interested in it. Thanks guys for this, we do apreciate your eforts. Mostly because your efforts rock :D
-
hey, I just thought of something, why don't you make this use the FEs graphics class, it'd give me a reason to work on it again, and kill two birds.
-
death to birds! :D
*hands bob one of his miniguns*
-
we could do that - but i'd have to merge PCS2 into the ferrium codebase
not like i wasn't planning on putting support into PCS2 for ferrium models anyway
-
/*gets nukes gun*/
dude it's like a gatling gun... of gatling guns WTF!
them fuk'c birds are dead
-
Wait, what about a gattling gun of gattling guns of gattling guns....
Nuke, you never happened to see the unreal gattling gun did you? it was two 3 barreled gatling guns positioned so that they interlocked as they turned, awesome-cool.
-
eh, actualy I made that, it's a joke Nuke has a bit of a mini-gun fedish.
-
Originally posted by FireCrack
Wait, what about a gattling gun of gattling guns of gattling guns....
Nuke, you never happened to see the unreal gattling gun did you? it was two 3 barreled gatling guns positioned so that they interlocked as they turned, awesome-cool.
that was one of my favorite video game miniguns. not quite sure how the feed system would work on something like that. i also liked the q2 minigun as well, as it had realistic spinup/spindown and ammo consumption. realisticly a mangun would never be fired with out a fixed mount.
i tried to model a realistic gatling gun but truepace started slowing down when i got to 10,00,000 polies. i also learned my feed system is all wrong, i also realised there was was supposed to be a flexable conveyor belt that ran through the storage helix around the gun and back and dreven by several hydaulic motors in sync with the guns rotatation. the thought of modeling and animating som,ething like that kinda made me give up. anyway:
(http://server2.uploadit.org/files/nukebomb-mini.jpg)
-
:shaking: :wtf: :nervous: :jaw: holy ....! Well... bob... Think we can get that some how in game, and working? :)
-
Bobb's new submodel animation code! :D
-
i spent weeks on that thing and its still all wrong. had i animated the thing it would quite literally have thousands of moving parts. perhaps with a proper cad program i could design something that would really work.
-
I think that would do well for creating a loadout animation.