Glass Issue and Question (in a Fighter)
-
Hmm… having it point to another node in practice is less easy than it seemed in theory. There is no ‘pointing to’ at all. The only link I can think of, is the name of the .3db itself - which, then, should be the same as the node in the .mat file.
-
Yes, they are around 0.70000, but I often use 0.80000 or 0.75000 but it’s a matter of taste.
You wrote the new rhino’s glass totally unvisible. Have you made new mat file for the new rhino or it’s mat links to the orig lib mat?
If the second one I suggest to make a new mat for the 1.75 rhino.Moonhead wrote:
Hmm… having it point to another node in practice is less easy than it seemed in theory. There is no ‘pointing to’ at all. The only link I can think of, is the name of the .3db itself - which, then, should be the same as the node in the .mat file.
Errr… I’m not sure I understand what you mean…
-
Davis wrote:
Yes, they are around 0.70000, but I often use 0.80000 or 0.75000 but it’s a matter of taste.
You wrote the new rhino’s glass totally unvisible. Have you made new mat file for the new rhino or it’s mat links to the orig lib mat?
If the second one I suggest to make a new mat for the 1.75 rhino.I used the original one.
I’d be willing to create a new file, but I’m kinda puzzled with how the files are setup… I studied a couple of bases a while ago and had assumed ships would work the same. But it’s more difficult imho.
How to create a new .mat? (I guess I could use FLModelCloner but I work with the XML project, and UTF-XML still doesn’t work… And I suppose that anything that FLmodelCloner does automatically, I can also do ‘manually’ do in the XML files that build the Gunship.
So, how to make it use another .mat??
-
Davis wrote:
Moonhead wrote:
Hmm… having it point to another node in practice is less easy than it seemed in theory. There is no ‘pointing to’ at all. The only link I can think of, is the name of the .3db itself - which, then, should be the same as the node in the .mat file.
Errr… I’m not sure I understand what you mean…
I mean that in the .XML files (which are the .cmp and .3db files converted into text XML files) there is no obvious explicit reference to a mat file.
Of course, there is a line in ShipArch.ini, but just changing that is supposed to render conflicts (if two objects -in my case, the original Rhino and the new Gunship - refer to different files with the same name, it might screw up.)
-
Vital wrote:
Use liberty gunboat from 88Flak(made by why485 I think).It has very liberty style
Thx for the offer / suggestion, but Id be more satisfied if I learn how to overcome the problems I ran into.
-
I think I found the material reference! It’s in the ‘lod’ files.
As they are in the same folder as the VMesh files (in the XML project) I didn’t find them at first.
Okay back to continuing trying/doing stuff now
-
This is weird: (I’m now working with a model the size of a standard Rhino, as the enlargement is the last phase in my ‘assembly line’) I see the new glass I made, when I fly the ship in space, but at the base (in the equip room, and also as a model at the shipdealer) the glass in invisible…
-
Screw it, the XML generated ship has issues (controls weird, even though its just a Rhino - not even enlarged now - with the exact stats of a Rhino. it’s not meant to be a flyable ship, but still I cannot comprehend why a cloned ship should have these issues.
FlModelCloner doesn’t seem to work properly. Prolly another Win7x64 issue. Well I never liked it much anyway tbh, I’m sadder about the XMLUTF which apparently has some issues, because the method it represents, makes perfect sense - in theory that is.
Don’t bother to respond; this is meant as a closing post of this issue.
-
Making new mat:
First, export the cmp model into ms3d with the mat files ( when the program asks for mat simply click the original lib mat).Second, export the mat from ms3d. Not a bad idea if the mat and the cmp names are the same.
For example: new_rhino.mat, new_rhino.cmp and of course new_rhino.sur
All you need are: mat.exporter, cmp importer/exporter for ms3d.
You can get these packages from the ‘download’ section I guess.I think you’re familiar with the FL_Model Tool, so I ignore the third step.
When you have the new .mat file everything is going to be default. You can easily set your values if you open the liberty mat by another utf editor and simply copy/paste the RGB values (only the values: Dc, Oc) to their proper place, and of course if you want to get glowing textures like the windows have then you must add Et, Ec nodes and their values/names.
I’m by no means an expert on XML so I cannot help with that.
-
Sizer wrote:
there’s this wonderful thing… it’s called the edit button.I agree. It’s particularly wonderful because there’s always the choice whether or not to use it.
-
@ Davis: thx for the info, but I’ll leave it at this.
Btw I haven’t had had a working Milkshape for years (I believe because I erroneously upgraded to a version that did not support the plugins). I contemplated getting a new version some months ago, but there was a rumor that in the foreseeable future it wouldn’t be necessary anymore. So, I decided to wait.
Not anymore, in fact I think I’ll just quit modding. I don’t wanna spend time to discover certain errors are because some functions in the tools don’t work well with Win7 x64
etc. etc. My stepson just started on university, programming Java a.o… I might get a better kick out of trying to keep up with him.Thanx anyway.
-
You can’t quit that easily man. Make the damn ship!
-
Lol, was rly tired last evening and also rly frustrated because I dedicated my whole evening to it, and I’m still sad about the XML project rendering unpredictable results, because it would be such a nice and clear way to do stuff like this.
EDIT: I deleted each an every file that was remotely involved with the ship, and then started anew - using XMLUTF. I did everything exactly the same way as I did before. However, the result differs: the ship works fine now :crazy: No glass issue, no steering issue. No idea where the corruption has come from, but I’m very glad it’s not in XMLUTF!
Now, I gotta enlarge the thing, which isn’t hard. After that I’m done
-
Enlarging the ship triggers some issues (no glass, and some kinda ‘lid’ on the back of the ship is lower than it should be) but i’ll open another thread for that.
-
you can map texture to glass simply by creating a new node for the texture in texture library, then under material library, you refer to the texture image node name in the string value of Dc… making the glass DcDt.
As for the reason the glass doesn’t show, I’d have to guess as you cloned the model, there is likely some cross referencing going on. I had similar texture issues where the ship would look good in a base or on a planet, but soon as it launched to space, the textures reverted back to vanilla textures… even though I was pointing it to a whole different .mat file that didn’t have the vanilla textures inside.
What I had to do to fix this is use Freelancer XML Project to decompile the .cmp and .3db files… renamed them all, updated the xml files to point to the new names… then did the same thing with the image and .mat files. Make sure to select “extract images” when you run FL XML Project, else you probably won’t get the desired results. Once your xml files point to the custom named part (or image) files, run XMLUTF to convert the modded xml’s and texture files back to the .mat, .cmp and .3db files… After that, it’s just making sure the shiparch.ini file also points to the appropriate files.
As for the pilot looking 1.75 times the size, if I’m not mistaken, the pilot is loaded from shiparch.ini and should be same size regardless, unless you’ve cloned the ship_pilot.3db…
Edit:
I guess it’s important to add that I did not use a cloning tool, but copied the files from their vanilla folders, created new folder and renamed each file… then retextured through UTF and Freelancer XML Project… perhaps the scaling of the ship could be placing the glass and the “lid” in inappropriate areas… you may need a 3d editing utility to resolve that issue. :? -
Ah… Something I actually know the answer on. I was doing a little research on this matter, and I figured it out. Digital Anvil never used a glass texture, rather they use a color instead.
Research Ship: cv_elite.cmp (Ship from NY System)
After importing into Milkshape, I went to the Materials Tab and saw that there was no texture. Instead there was a light brown color being used that was slightly transparent. Color settings were:
Ambient: RGB=25
Specular: RGB=25
Emissive: RGB=25
Diffusive: R=167,G=135,B=81
and the Transparent bar was set above the “o” in None.In UTF Editor I found the texture in the Material Library and found these Nodes:
Material Library
->cv_glass
–>Type
–>Dc
–>Oc
The data for each node was
Type…DcDtOcOt
Dc…The color in a 0.xxxxxx RGB color hexadecimal number
Oc…0.800000 <-the percentage of transparency, 80% in this case
…0.000000 <-a second number needed for the transparency, don’t know why.Now if you were to look in the mat file rh_playerships.mat as shown in my glassrearch.jpg file, you would see the r_glass in the Material Library, but not the Texture Library. This is how it was done.
Fus
-
I did it the way Fusion suggested for about a week before I got sick of looking at a single color on my ship that didn’t match the rest of the texturing even though the colors were about a 98% match… so I found this way to texture the glass…
Add a node under texture library for the image you want to texture the glass to… then in material library, type is DcDt, no Dc node necessary (but may still control transparency/opacity; not sure as I did the transparency in the .tga file)…
Dt_name string value should be the name of the node under texture library.That is, of course, if you don’t want just one standard color for the glass… ex) a camouflage texture would prob want textured glass…
