graphicmesher3d.exe

A forum for the discussion and development of programs to assist working on or playing with the Vegastrike engine and data sets.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

graphicmesher3d.exe

Post by chuck_starchaser »

I was thinking about the ideal tool for artists, rather than a GUI for mesher, what would really rock is a ship visualization tool that integrates bfxm AND units.csv production.
  • First of all, using just ANY test scene is not right. There should be ONE test scene for all artists to use. Your ship should appear in a fixed location, near a station that in turn orbits a planet, and a few stationary ships nearby, so that one can tell, at a glance, how one's ship compares to other ships in terms of materials used and overall diffuse brightness and specularity.
  • Secondly, it should allow you to move forward, to see if the ship's mesh orientation is right (but the ship should spring back to the original position when you release the throttle), and to change it otherwise (90 degree rotations).
  • Thirdly, there should be a gui window in a corner that allows you to add .obj meshes and textures, choose blending mode and technique, add LOD's, etceteras. All changes of parameters and reloadings of obj's or textures should have immediate effect on the ship viewed.
  • Fourthly, it should allow you to position weapons, subunits, engine exhausts and pilot. Actually, first of all it should allow you to copy the units.csv data from another ship by entering the ship's name. Check boxes for .blank and .template, etc.
And there should be a Save button which:
a) produces a folder under units
b) saves the bfxm and textures to it
c) saves the modified units.csv
e) saves a diff to apply to units.csv, to submit with the package

Dreaming is cheap :)

But consider this: The payoff would be enormous: Artists would finally be able to be productive, for a frigging change.
And it doesn't seem to me it should be THAT difficult:
Basically, a modification of the engine whereby the "test mission" is hardcoded, the incorporation of mesher code (or calls to mesher.exe), and a GUI.
The GUI, if it makes it easier, could be a full-screen GUI that you toggle on or of with, say, F9.
The rest is just Python :D

If there's interest in this, I could start designing the GUI layout.
Last edited by chuck_starchaser on Tue Jul 01, 2008 3:31 pm, edited 1 time in total.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

Have you thought about a widget set for the GUI the WXwidget set is not bad and supported on all our platforms(linux,Windows and OSX) and there is a good set of python bindings for it as well as a GUI designer app that should make that design job a bit simpler :wink:

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Thanks; I'll look into it.

EDIT:
Damn!
There's an installer in the sourceforce download, but sourceforge doesn't seem to be working; click on the download page, nothing happens; click on the direct link, nothing happens.
Then I look at the mirrors, and they have zips, not installers.
No problem.
I download the zip. Look at the instructions. Says that a setup.exe is provided, but it's nowhere to be found.
Why do they have to make things so difficult?
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

I whole-heartedly second this request/suggestion.

The VS code team has said they need artists to make updated models that utilize all the new shaders and make the power of the engine they have made obvious to the public in so doing.

Well now we on the art side are responding that to do this for you and all of our users, we need this tool so that there is not such a barrier between creating things that look great and creating things that will look great in-game in Vega Strike. In nearly the words of a hyperactive scientologist madman- 'help us, help you!' :)
rivalin
Bounty Hunter
Bounty Hunter
Posts: 153
Joined: Sun Jul 15, 2007 2:16 pm

Post by rivalin »

Thirded! :D

I really, really hope this idea will get somewhere, it might seem like a small thing, but any other work on the more impressive elements won't do that much for the popularity of the engine if there's one overriding bottleneck in the production process. Good tools will be inavaluable for the future progression of VS, because as technology advances and the artwork required becomes more complex, they become more and more necessary.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

Note on future proofing this little app reminder that the mesh format will change to OGRE's .mesh when we finally move to it.

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Thanks for the support, guys.
I'd love some dev feedback on feasibility, comments about features, etc.
Could we set a release target for this tool?
BTW, for positioning of weapons, etc., I meant nothing fancier than x,y,z for postion, forward and up vector entry boxes; but with the item showing on-screen, so that one can adjust those numbers and see the results instantly.

EDIT:
BTW, one feature I forgot to mention is the reload button.
The tool should keep the date/size of every input file (.obj/.texture) it is using.
Hitting RELOAD would make the program check the date/size of all the files on disk and compare them to its stored values, and refresh the display to use the newer versions.
This would enormously reduce the modify/test cycle time.

Also, BTW, it would be important for this program to detect when its window is minimized or covered, and try to use as little CPU as possible.
The idea would be that artists can alt-tab between graphicmesher3D.exe and other modeling and graphical apps, and NOT have the other graphical apps slowed down by this app running in the background.
Preferably, it would destroy its own target surface, and restore the graphics card to its original state, whenever you alt tab away from it; and then recreate it when you alt-tab back to it; --so that apps like Blender, that use OGL for screen display, aren't affected by the app's graphical state.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I'd rather see any tools made for VS to be written in python using tkinter so that all OS's are supported out of the box.

There is no reason not to have every tool done this way.

tkinter is installed with python, thus i would consider it more cross platform than wx.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

The aspect of not drawing when it's covered is the Windowing Systems's responsibility, not the app. All the app has to do is respond to redraw signals that the Windowing System gives it. Xorg and such friends will handle all the gory details.


Basically what i was thinking of is having a mission file in VS that loads the game with a given ship model and texture via hqtextures type methodology. The app can make a temp config file, set the hqtextures dir to the working dir tree is creates that mimics a real /data dir but only contains the unit you're working on and a modified units.csv with your unit added in with some selected values.

Thus, the app can "render" your unit by executing VS within a window attached to the main app using this special mission that loads a basic scene along with your unit that VS reads automatically via hqtextures (which is basically the same as having a mod but allows you to set an external dir). A modified config could provide some very limited key usage for changing views and rotating and zooming.

This way, we dont have to recreate all kinds of code to get your model to render like VS.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

safemode wrote:I'd rather see any tools made for VS to be written in python using tkinter so that all OS's are supported out of the box.

There is no reason not to have every tool done this way.

tkinter is installed with python, thus i would consider it more cross platform than wx.
Your wish is my command. *Reading tkinter's tutorial.*
If it makes it easier, this could be split into two apps: A visualizer, being a modified vegastrike.exe, and a stand-alone Python+Tkinter app.
safemode wrote:The aspect of not drawing when it's covered is the Windowing Systems's responsibility, not the app. All the app has to do is respond to redraw signals that the Windowing System gives it. Xorg and such friends will handle all the gory details.
k. I hope it works in XP :D
Anyways, what I still insist on is that the app should detect when it's not in focus and the main loop should relinquish control (Sleep(777)); otherwise Vegastrike does take cpu time, even when minimized. And we can remove unnecessary parts of the code, such as sound, AI, collisions...
Basically what i was thinking of is having a mission file in VS that loads the game with a given ship model and texture via hqtextures type methodology. The app can make a temp config file, set the hqtextures dir to the working dir tree is creates that mimics a real /data dir but only contains the unit you're working on and a modified units.csv with your unit added in with some selected values.

Thus, the app can "render" your unit by executing VS within a window attached to the main app using this special mission that loads a basic scene along with your unit that VS reads automatically via hqtextures (which is basically the same as having a mod but allows you to set an external dir). A modified config could provide some very limited key usage for changing views and rotating and zooming.
Or, like I was saying above, this app could be just a python gui and the visualizer be separate. This would be better because, as an artist, you'd want to look at details, and this requires full-screen, rather than a window in an app that hardly has enough room for all its data input boxes and buttons.

This way, we dont have to recreate all kinds of code to get your model to render like VS.
I think the visualizer needs to be a modified vegastrike.exe, because, at minimum, you need a Reload meshes and textures function, which vegastrike doesn't currently have.
Besides, it would be best if the test scene was hard-coded, and the drag and drop function changed so that you can drag and drop a ship folder into it, rather than a mission.

BTW, the Python app would need two main folders with an explorer browser widget to set: Source folder and Output folder.
  • The Source folder would be where you do your artistic work; --where you png textures and .obj/.mtl files are.
  • The Output folder would be a shipname folder under the /units folder.
The python app should also save a project file, so it can be reloaded with all the settings as they were the last time.
Should also have a button to "launch visualizer".
And a config file that contains the path to the vegastrike root folder and its own vegastrike.config substitute.

Perhaps a solution that avoids having to compile a modified vegastrike.exe would be to have the python app launch plain vanilla vegastrike.exe with the right mission and ship; and a button [Refresh] that kills and relaunches vegastrike.exe.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

the app only knows what the windowing system tells it. With XDamage and such, i believe such events can be caught by the app and it can halt rendering at the app level, though a great deal of cpu is saved by just letting the windowing system do it's job. I would not suggest overcomplicating things just for this feature though.



As for the visualizer. VS doesn't need to be modified to do what you want really, well not heavily. What we need to do is simply provide the api to flush data from the cache. We can do this without heavy modification. This would in turn cause VS to have to re-read the mesh and texture data from disk. This reload function would be specific to this mission, executing a special function that would never be called by any other mission. Basically, just clearing the cache.

So we load a unit into a scene. Play with it. Edit it in the editor again. Hit reload. Then reload does a sequence of things.
1. It clears the cache
2. It destroys the unit in the scene using normal unit destruction methods (self destruct)
3. It re-spawns the unit (forcing a read from disk now)


These features would not require a special VS compile, as they would not interfere or change the game.

All you would need is the python app, some free disk space, and a working installation of VS. The _only_ trick that i'm not totally sure about being able to do without a little VS modification is embedding the GL window that VS creates into our python app. Since VS would be executed as it's own process, i'm not sure we'd be able to do that. But that may not be a big deal.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

That's great news!
safemode wrote:The _only_ trick that i'm not totally sure about being able to do without a little VS modification is embedding the GL window that VS creates into our python app. Since VS would be executed as it's own process, i'm not sure we'd be able to do that. But that may not be a big deal.
Like I said, we'd rather NOT have a 3D window, but much preferably a toggle between the app and full-screen 3D. The purpose of the 3D display is not decorative, but rather for serious visual inspection; so it needs to be full-screen.
In fact, I'm thinking we could make the [~] key both a toggle and a refresh key: When you hit ~ while in 3D view mode, it toggles to the app gui; when you hit it again, it toggles back to 3D AND calls Reload.
Fendorin
Elite Venturer
Elite Venturer
Posts: 725
Joined: Mon Feb 26, 2007 6:01 pm
Location: France, Paris

Post by Fendorin »

what happen with this tools-project after 2 month
it is finish???

i am very (very you should believe me) interressed by this tools !!!

thank
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I think (or at least I hope) this is coming after the CineMut-related engine changes are done, tested and committed, namely Techniques, Tangents and CubeMaps. Well, Klauss is keen on working on the sound system, but I'm trying to convince him to give the art pipeline top priority.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

What's really needed is another active developer... Klauss can't do everything by himself.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

charlieg wrote:What's really needed is another active developer... Klauss can't do everything by himself.
I think Safemode is on vacation. The big problem right now with CineMut is the lack of cube-maps. Well, Klauss got them working, sort of, but they look like crap because they show seams on the blurred reflections; and that's because, although ATI's CubeMapGen tool can produce correctly filtered cube-maps across faces, it saves them to a unified cube-map format; but the engine doesn't have the code to read that format. And now Klauss' 6800 videocard died... :(
Post Reply