UnitConverter obj->bfxm

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:

Post by chuck_starchaser »

pyramid wrote:What are you intending to do with the following line in cinemut_opaque.technique:

Code: Select all

<texture_unit src="file:moto_PRT.png" name="prtMap"/>
Can it be simply deleted once we can now put the PRT into the unit itself? Or are there other implications that are escaping me?
I've no idea; you could try and see if it works without that line. In theory it should; I think Klauss put it there just for a quick test.
The updated ruler ship (my favorite vessel Wink ) was also committed for those who may see use in it (for I will test it as a space piano Idea).
Are you saying you have no use for it? I thought that's what you wanted :-/
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

chuck_starchaser wrote:Are you saying you have no use for it? I thought that's what you wanted :-/
Actually it was Fendorin who has requested it. It has also been requested several times in the past. So it's not all lost work. Maybe I was joking too much. It is really a fine ship.

The ship can become really useful when wanting to show scales ingame, so it might come in handy at a later point in time. I can imagine e.g. putting it by default into the modelview.mission near the base that is there so that artists can fly close and have the sense of scale.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Well, frankly, I never actually thought it should be terribly useful, as the length of a ship is easy to calculate as mesh length x bfxm scale parameter x units.csv scale parameter; however it's always good to have an independent method to confirm error-prone things; but no such method existed till now.
What would be better, of course, is making VS itself capable of showing a grid in space, centered on the ship; and have the grid on by default in modelview; but there's more things to do than programmers, and this sounded easy to do as a ship.
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

If one is looking for models of known size to benchmark a new model against, then one would think 1:1 scale models of doors and people and trees and space shuttles and celestial teapots and such might be useful for lending additional reference beyond absolute size metrics (which may not be as easily internalized as the relative ones for all artists).
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

Then chuck's wee pilot model could drift about in the test mission for a quick reference to human scales.

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
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

While programming further stats editing for UnitConverter, I have found that for shields, armor and hull strength the unit "VSD" is used in units.csv. What does it stand for?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Sure; I could throw in an Empire State Building too :)
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

pyramid wrote:While programming further stats editing for UnitConverter, I have found that for shields, armor and hull strength the unit "VSD" is used in units.csv. What does it stand for?
If I were to take a guess... "VegaStrike Durasteel" (cm-equivalent). :)
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

Vega Strike Damage (unit).
Expressed in joules. Magnitude configurable via config file.
Current value: 1 VSD == 5.4 MJ (for slightly misguided historical purposes not worth revisiting here, but made reasonably obvious by the alternative listed below)
If we wish to have a slightly rounder number, we could change it at some point to 4.18 MJ
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Re:

Post by pyramid »

Thanks.

Unit Converter v0.33 brings some more unit stats editing possibilities:
* mass
* upgrade volume
* hold volume
* fuel capacity
* hull, shield, and armor strengths (VSD!)
* shield recharge rate
* moment of inertia
* maneuver

Is maneuver for the lateral thrusters?
Fendorin
Elite Venturer
Elite Venturer
Posts: 725
Joined: Mon Feb 26, 2007 6:01 pm
Location: France, Paris

Re: UnitConverter obj->bfxm

Post by Fendorin »

Maneuvr ? maybe is the maximum maneuvr speed?

who knows?
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Re: UnitConverter obj->bfxm

Post by jackS »

The 6 maneuver categories are for yaw, pitch, roll and their respective governors.

Forward, retro, left, right, top, and bottom are the 6-axis thrust ratings. The afterburn field overrides the forward value when used.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Re: UnitConverter obj->bfxm

Post by pyramid »

It seems to be more complicated than that. In units.csv there are distinct column groups, where my interpretation based on the measurement units is:
* Default_Speed_Governor -> maximum forward speed
* Accel (forward, retro, left, right, top, bottom) -> maximum linear acceleration
* Afterburner_Speed_Governor -> overrides speed with overdrive installed
* Afterburner_Accel -> overrides forward acceleration with overdrive installed
* Governor (yaw, pitch, roll) -> maximum angular speed
* Maneuver (yaw, pitch, roll) -> maximum angular acceleration

Whatever the case, in the next version UC will provide editing facilities for all this properties.

*EDIT*
Most of the basic unit editing is implemented. I have doubts as to the use of the Upgrades vs. Cargo column. It seems that the cargo entries also consist of upgrades in most of the existing cases.

Another doubt is related to the integration of blink lights. Is this done in the mesh, as I don't seem to find any reference to it in units.csv?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UnitConverter obj->bfxm

Post by chuck_starchaser »

Indeed. Blinking lights are implemented by the xmesh calling for a .spr file, instead of a texture. The .spr then calls for a sequence of textures.

I've got an idea that might be almost OT here, and might not be warranted at all; not sure; just an idea...

The fact that textures for models are called from within the xmesh/bfxm files has always been a problem:
1) It's a maintenance problem, because, for instance, in PU there are many model textures that just don't show, probably due to filename issues
like capitalization; but there is no way to find out except by converting ALL models' bfxm's to xmesh and looking at the names specified.
2) It's an efficiency problem because you can't have, say, pirate, militia and retro talon textures sharing a common bfxm; they need to have
separate bfxm's.

Gorbalad is finally tackling this problem in PU, converting all bfxm's to xmesh and putting the texture names next to them in a spreadsheet.
http://xover.htu.tuwien.ac.at/~cohen/PU/textures2.xls
We are going to put this spreadsheet in the /units folder, and keep it up to date, so that in the future we have a doubt about what textures
a given model uses, we just look at this document, instead of having to mesher up the model.

So, I thought, wouldn't it be nice if UC would maintain such a document automatically?
Then I thought, wouldn't it be nice if this was a csv format spreadsheet and the engine used it?

And what I'm thinking is that if UC generated such a csv it would be useful in itself, as a document; and by its being there it might make
it very simple at some future date for the engine to switch to using it, rather than the bfxm, as the place to look for textures.

Just an idea.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Re: UnitConverter obj->bfxm

Post by pyramid »

chuck_starchaser wrote:1) It's a maintenance problem, because, for instance, in PU there are many model textures that just don't show, probably due to filename issues
like capitalization; but there is no way to find out except by converting ALL models' bfxm's to xmesh and looking at the names specified.
2) It's an efficiency problem because you can't have, say, pirate, militia and retro talon textures sharing a common bfxm; they need to have
separate bfxm's.
I don't see how additional tracking in an external tool would help you identify problems. It's double work tracking externally textures in the case of an update. I hope the following will help you remove the cause instead of remedying the symptom.
Re 1) With UC you can now simply point to a bfxm and, in the "Textures" tab, it will show you in the textures used in the bfxm file. Here you can easily check if spelling is correct or if/where/which texture is referenced from that file.
Re 2) For faction textures the standard is to prefix your normal textures with the faction name, no need to have a separate bfxm file for factions. E.g. your ferret.bfxm has texture="ferret.png". For the "civilian" faction you would just add the "civilian_ferret.png" texture to the same directory where ferret.png resides, then maybe add "pirate_ferret.png" and so on for other factions. That's all. True, in UC faction naming is currently hard coded for VS factions, which shall be changed to be read from factions.xml.
Such things as the faction textures convention should be documented and it's on my plate, just don't know yet how I'll organize all the info. The portal page for models creation and integration will be http://vegastrike.sourceforge.net/wiki/ ... Guidelines though I haven't even properly started. OT, just today I did restructure the Development page. It should make more sense now.

UnitConverter v0.34 is done with following functional additions:
* integrated simple forward/backward browser through units.csv
* added editing facilities for speeds and accelerations (both, linear and angular)
* added editing of capacitors, jump drive, overdrive, SPEC drive
* added editing of radar parameters, cargo
* joined marker-based mounts (turrets, subunits, docking ports, engines) on one tab
* renamed "Mount" to "Marker" for required obj file name part
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: UnitConverter obj->bfxm

Post by charlieg »

chuck_starchaser wrote:Gorbalad is finally tackling this problem in PU, converting all bfxm's to xmesh and putting the texture names next to them in a spreadsheet.
http://xover.htu.tuwien.ac.at/~cohen/PU/textures2.xls
Don't use Excel... :(

http://www.gnumeric.org/
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:

Re: UnitConverter obj->bfxm

Post by chuck_starchaser »

Nobody's using Excel, CharlieG; Open Office; but I just grabbed Gnumeric out of curiosity.
Looks like it's got a lot of functions and better graphing; thanks!

@Pyramid:
Gottcha, thanks!
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Re: UnitConverter obj->bfxm

Post by pyramid »

Unit Converter v0.35 comes now with support for submesh texturing and conversion support.
Other than that I have added the Cargo_Import column to the units.csv editor. This column controls the cargo available for sale at a station.

In terms of mesh conversion I am missing the integration of blink lights. From what I understood, lights are separate objects that define the animation sequence for blink lights, e.g. animation="blink.ani". I haven't yet come around to analyzing the nature/shape of the blink light object. It would be however nice if we could add a marker object in blender to include the blink light positions in the main mesh export and subsequently for UnitConverter processing for bfxm conversion. Any thoughts on that are welcome.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UnitConverter obj->bfxm

Post by chuck_starchaser »

I haven't used them yet; been planning to for a long time. The story with blinking objects is basically that, instead of specifying a glow texture in xmesh, they specify a .spr which in turn calls for two glow textures (on and off emissive colors).
Now, theoretically, you could generate two glow textures for the whole ship or station, but this would be highly inefficient. It would consume a lot of cpu and gpu to be switching 2k by 2k textures. So what you do with blinking lights is make them a separate submesh with a small texture, and then give only them the two (small) glow maps and flashing .spr.
I'm not sure that helper objects would help with this. But now that you got submeshes, maybe you can make a distinct type of submesh for blinkers, that asks for two or more glow maps and a sequence of on/off times and it generates an .spr for you.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Re: UnitConverter obj->bfxm

Post by pyramid »

The principle is clear. That was not the question.
My point is, because lights are submeshes, it would be useful to have a helper submesh that one could simply import and position and UnitConverter would recognize this submesh as a blink light submesh by its name (e.g. "light") and then use this as a reference to ask for a corresponding animation file.
Btw, the submesh uses the .ani files, not .spr from the data/animations directory, for example data/animations/redlight.ani for a red blinking light. The submesh reference is done through the "animation" instead of the "texture" statement.
My question was of a much simpler nature: should the submesh be a sphere or 2 or 3 perpendicular squares?
Yesterday I didn't come around to it anymore, but now, that I have extracted the blink light meshes from the Llama, I can say that the case it the last one: 3 perpendicular squares. I hope the road is now open for UC to integrate that part.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UnitConverter obj->bfxm

Post by chuck_starchaser »

I see.
How about just having a standard naming convention, like "<yada>_blinker". I'm not sure it's wise for UC to predetermine the shapes for lights.
If, say, for instance, I want blinking lights mounted on towers with step ladders and scaffolds, I'd do a radiosity baking of the scaffolds and add
them to the blinking light mesh, so they look like they are receiving illumination from the blinking light. That's in fact a plan I have for the
PU mining base and Perry; and I might use it for VS's mining base too.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Re: UnitConverter obj->bfxm

Post by pyramid »

Got you. My idea is to not restrict the possibilities of modeling and at the same time allow for easy integration of standard features. The blink lights helper would be a standard one and only serve for the standard bluelight.ani, greenlight.ani, redlight.ani, and whitelight.ani that are available in the data set. With this, the modeler would only need to import the standard light, place it on the mesh and the rest would be taken care of by the unit converter, including assignment of blink colors. In this way blink lights could be placed without much additional modeling and texturing effort and for those who want it. This, so far, the idea.
Of course, one should also be able to do one's own light shapes and textures/animations without resorting to the standard shapes and UC would know by the naming convention that it has to convert that submesh with animation parameters on.
Both ideas seem very compatible to me I just need test cases for yours to make sure they can coexist in the processing. For now I'll be implementing the standard blink lights, and later can extend this to generic blink lights.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UnitConverter obj->bfxm

Post by chuck_starchaser »

Sounds good to me. You could call your standard lingts red_blinker, green_blinker, blue_blinker, yellow_blinker, purple_blinker and white_blinker, say; and one could just grab one of them, modify it to add geometry or change the shape, and call it modded_fuscia_blinker or scaffolded_white_blinker, and that's it.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Re: UnitConverter obj->bfxm

Post by pyramid »

UnitConverter v0.36 supports animation textures for blink lights. There is also a set of helper objects under UnitConverter/helper/blink_light-submesh.blend.
What you do to integrate the standard blink lights, is append the objects in blender and position them in your mesh and then export them together with the main mesh. The only difference to the mount marker object is that you export the lights not separately but together with the mesh.
In UC, you just point to the submesh and in texture 0 (diffuse) point to the corresponding ani file. I have included touched ani file names for the four light colors. The idea is, you copy the complete helper subdirectory to your model working directory and from there just point the references without needing to navigate your directory structures to find the vegastrike/data/animations folder :D.
The feature is actually alpha version as I didn't have time to completely test the workflow yesterday but still thought this development might be worth sharing asap.

OT, when playing with the new blender 2.48, I have uncovered a bug in the obj file export, which will not export the object names no matter if the export buttons (object or group) are pressed or not. This seems to be due to an updated python api which is not yet linked correctly to the export script. As a workaround, in blender 2.48 only, you can add the following line 342:

Code: Select all

			EXPORT_BLEN_OBS = True
I'll have to report that on the blender forums.
The thing is that UC requires object names, otherwise it will just assume everything is a unique mesh and I didn't want to go the material way, since one object can consist of more than one material.

Blender 2.48 comes with a very very very useful feature: it will mark those layers that have objects with a point on the layer squares. :!:

*EDIT*
Seems the problems with object export have been solved in blender 2.48a

A question regarding blender. When joining objects for export, is there a way to unjoin them again? Or is it better to copy the objects before joining them and then keep one joined and one unjoined copy?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UnitConverter obj->bfxm

Post by chuck_starchaser »

pyramid wrote:A question regarding blender. When joining objects for export, is there a way to unjoin them again? Or is it better to copy the objects before joining them and then keep one joined and one unjoined copy?
Not sure I understand why you'd want to "join objects for export". In my mind, if you want to joint them for export you want to join them, period. But, generally, whenever I need to do special tweaks for export I just save the file, then save-as again adding "_objexport" to the name. There's no way to un-join objects; --except via undo (if you are lucky and it works). Or you could give the object you'll want to unjoin later a new material, then later you can select by material and P to split it.
Post Reply