CT-2000 - LIHW Wake Industries Corporate Shuttle

Thinking about improving the Artwork in Vega Strike, or making your own Mod? Submit your question and ideas in this forum.

Moderator: pyramid

rivalin
Bounty Hunter
Bounty Hunter
Posts: 153
Joined: Sun Jul 15, 2007 2:16 pm

Post by rivalin »

Fendorin wrote:OH very nice ship very nice design too

and very good rendering picture (i like lighty thing)

it can be a aera boarding craft : the POLYDORUS no???

it look like renforced ship for find way under fire, delivery aera marine special assault warrior and return to big unit or stay near the front-line(if it s possible to have a front line in space)

i thougt corvette size no??
it don't look like a fregate or fighter size but more like an armed and agile corvette !

plus i thought Boarding unit could be a first target of new mission ;title :
defend ship/planet/station to the marine troop invasion!!!

Thanks, it is corvette sized (bigger than fighter, smaller than frigate), and it is meant to be a fast transport ship, and it was originally meant to be for the Aera, but now it's probably just going to be a civilian transport because it isn't "aera-ish" enough :)



Chuck; I'm going to try and do some quick textures, I've been doing some work on the ship, and I've got a UV, though a somewhat patchy one, and I've managed to do some AO bakes, but I could use some advice on certain things;

1.I've seen some people on here mention leaving AO bakes over night, the ones I've done have taken <30 seconds, I'm thinking it may be something to do with the settings for the number of rays (128 right now) , what would be an apporpriate number for in game.

2. Modo can output a ton of different bakes (spec amount, spec colour, spec fresnel, reflection amount, reflection fresnel, reflection colour...) , and perhaps in a non standard manner, what are the standard maps that VS supports, and are a number of channels merged into single textures?

3. What did you mean by using the AO bake to modulate the other bakes, is that something that has to be done in before rendering, or is it something on the VS end?

sorry for all the questions, I just want to make sure the model doesn't end up as an unusable mess. :)
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

rivalin wrote:Chuck; I'm going to try and do some quick textures, I've been doing some work on the ship, and I've got a UV, though a somewhat patchy one, and I've managed to do some AO bakes, but I could use some advice on certain things;

1.I've seen some people on here mention leaving AO bakes over night, the ones I've done have taken <30 seconds, I'm thinking it may be something to do with the settings for the number of rays (128 right now) , what would be an apporpriate number for in game.
Blender has a different numbering for this setting. In blender, the number of rays is the square of the setting. Thus, 16 means 256 rays. I do my test bakes at 16, but final bakes at 32 (1024 rays). However, even with only 128 rays, 30 seconds sounds too short a time to me, unless you own a Cray... I'm only familiar with Blender, and in Blender there are other settings that affect quality versus speed. One of them is distance to check for ray hits. That distance should be a bit longer than the maximum ship dimension. Another parameter is Plain vs. Sky. Plain uses white light for the bake. Sky uses the sky color. I use Sky, and give the sky the color 0xFFFDFA (almost white but not quite). The point of it being giving the three channels slightly different multipliers, so that the quantization steps of the three channels aren't simultaneous. I figure that gives an extra bit or so of color precision. During blending/modulation of the textures, Blender's nodes can use the extra precision, as nodes work in 32-bit floating point precision per channel.
2. Modo can output a ton of different bakes (spec amount, spec colour, spec fresnel, reflection amount, reflection fresnel, reflection colour...) , and perhaps in a non standard manner, what are the standard maps that VS supports, and are a number of channels merged into single textures?
spec amount = a black and white version of specular color. Useless.
spec color you want.
reflection color = spec color, unless the material is wrongly defined :)
spec fresnel and reflection fresnel should be the same, so let's call it just "fresnel", it would be a function of the material's dielectric constant. Non-dielectrics, such as metals, reflect in a fairly straightforward way, like a ball bouncing off a wall. Dielectric materials, such as water, glass, the surface layer of glossy paints, etceteras, reflect in a different and partial way which depends on the angle to the surface and the light's polarization. In the shader I'm working on right now, for glass we will have an approximation of fresnel reflection; hopefully I'll finish it this weekend. The new opaque shader I just finished but haven't tested yet also has fresnel reflection capabilities, so you can make gray glossy paint look very different from metal of a similar shade. Now, the question is, have you defined the fresnel indexes for your dielectric materials? If not, baking fresnel will do nothing for you. If you do define your dielectrics, and bake a fresnel texture, I'd love to take a look at it, see if I can use it.

What you really need to bake is diffuse color and specular color, to two separate textures, of course; plus the ambient occlusion.
3. What did you mean by using the AO bake to modulate the other bakes, is that something that has to be done in before rendering, or is it something on the VS end?
The new shader I just mentioned, yet untested, will do the modulations for you at runtime. All you will have to do is throw the ambient occlusion bake onto the alpha channel of the glow texture. But it may take another week or two or more before this shader, and the engine code it depends on, are put into trunk. So, for now, you could just do the modulations manually.

You'll need two additional versions of the ambient occlusion: One gamma-brightened (0.5) and one gamma-darkened (2.0). This is equivalent to computing the square root and the square of AO, respectively.

The difuse texture is the brightened AO multiplied by the material diffuse color.
The specular texture is the darkened AO multiplied by the material specular color.
The glow texture begins with the plain AO multiplied by the material diffuse color. The result you multiply again by 0.125 (1/8), which makes it very dark, almost black, and then you blend your ligths texture on top, in additive mode. The purpose of the AO x diffuse x 0.125 is sort of model ambient illumination. It assumes ambient light to have a fixed color and brightness, but it looks good enough; much better than ogl ambient light.

The reason for modulating diffuse and specular by sqrt and square of AO respectively is a very long story; simply what looks best ;-)
Theoretically, diffuse should not be modulated by AO, but the lack of shadows in the engine can be made a lot less obvious with just a little bit of diffuse modulation.
Specular modulation by the high-contrast square of the AO is also theoretically incorrect, but it helps hide a limitation of the standard graphics pipeline: The lack of self-reflection or specular self-occlusion.

EDIT:
Ehm.... Gimp doesn't have stuff like gamma or square roots; you have to use the color curves and do a visual approximation.
Let me find a blender noodle that will do it for you; I'll be back...
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Here ya go:
http://deeplayer.com/lagrande/diffspecglow_mixer.blend
You need to get Blender to use it. Once you have Blender installed, double-click the blend file. It will look like this:

Image

The squares on the left are the input textures; the ones on the right are the output textures; the ones in the middle do the work. I have those scaling squares at 0.5, but you can change them to 1.0 if you don't want to scale down the images (or to 0.25 if you want to scale down more).
When you open the file you won't see images, because they are not there.
Just copy the file into your work folder, open the local copy, turn OFF the Use Nodes button, and fix the texture input and texture output filenames.
Every time you select an input or output texture, be sure to hit the relative path button. Once you're all set, turn Use Nodes on, and in a few seconds you have a new set of output textures.
Ehm... All your input textures have to be the same size.
rivalin
Bounty Hunter
Bounty Hunter
Posts: 153
Joined: Sun Jul 15, 2007 2:16 pm

Post by rivalin »

Texturing really does take a lot of effort

I've managed to get the workflow for rendering out all the textures done, and I've managed to get them through the noodle;



ImageImageImage


Do these look about right?


Couple more questions to if it's not too much trouble;

1. Complex UV maps just make texturing difficult, they don't cause perofrmance problems or anything?

2. What has to be done with the outputted textures? do you need a new model with the textures reassigned etc etc or do you just use the same file and rename the outputted textures to match the originals? What's the next thing needed, and is there a quick way you use to check if the materials have worked on the model effectively?, eg some kind of in engine ship viewer

Sorry if any of the above sounds a bit stupid :D
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

rivalin wrote:Texturing really does take a lot of effort
Hahaha, you ain't seen nothing yet... :D
I've managed to get the workflow for rendering out all the textures done, and I've managed to get them through the noodle;

ImageImageImage

Do these look about right?
You did well. This is my fault: I have the blending factor for the glow at 0.75, which implies that the brightness of the ambient component is 0.25, which, from looking at the middle picture, is too high; I should have known. You might want to make that blend factor 0.85.

The modulations are working as they should. What I cannot tell is whether your materials are well specified or not; but that's your call. I try to use materials that one normally finds, such as metals, paint, ceramics. Metals have little or no diffuse color; almost purely specular; and colored metals, like copper or gold, the diffuse and specular colors have the same hue and saturation; only different lumas. Ceramics I represent as all diffuse, no specular. Paints come of various types, but they vary between "matte paints" which aren't really matte, and like colored metals have specular and diffuse of same hue and saturation, to glossy paints, which have color in diffuse, but a shade of grey in specular.
One cardinal rule for realistic materials is that the sum of diffuse+specular cannot be more than 1.0, for any r,g,b channel. Otherwise, the material would be reflecting back more light than it receives.
Thus, a perfectly chalk-white surface would be white in diffuse, black in specular.
A perfect mirror would be black in diffuse, white in specular.
Or you could have a salty mirror by making the material 0.5 in diffuse, and 0.5 in specular.
But you CANNOT have a material that is 0.5 in diffuse and 0.6 in specular.
I'm looking at the bottom-left area of those textures and those big structures seem to be pretty bright on both diffuse AND specular....
In Blender one has to be careful, because its default material is precisely one such absurdity: Almost white in both diffuse and specular. So if you start renderings before setting up real materials, you end up turning the lights down too far, and then when you do start playing with the materials you end up making them too bright.

Let's call the sum (addition) of diffuse and specular colors the material's "albedo". Another way of putting this rule is that no material can have an albedo brighter than white.
But you shouldn't even be close to white, for most materials. Perfectly white materials don't exist. Even snow has an albedo of like 0.8. Real good telescope mirrors made of electrodeposited aluminium on the top of the glass, have albedo of 0.9.
Just to say that your diffuse and specular textures seem rather too bright.
For some typical metal, like stainless steel, you need diffuse of like 0.1 and specular of 0.5 or whereabouts. Aluminium is brighter in specular; but that's about the brightest metal.
Couple more questions to if it's not too much trouble;

1. Complex UV maps just make texturing difficult, they don't cause perofrmance problems or anything?
Indeed; along any lines marking UV island splits, the vertices are split (duplicated); so one of the terrible things automatic unwrappers do is to chop the UV map too thin, so the videocard ends up processing like 50% more vertices than it should have to. UV unwraps should be done manually, and with a lot of TLC. But for a temporary texture job, this will do.
2. What has to be done with the outputted textures? do you need a new model with the textures reassigned etc etc or do you just use the same file and rename the outputted textures to match the originals? What's the next thing needed, and
The next step is to export an .obj of your mesh, and use mesher to make a bfxm, then an xmesh, then edit the xmesh file to list the names of your textures, then convert back to bfxm.
Then your textures need to be, or should be, converted to dxt1 compressed dds format, which you can do with nvidia's nvcompress tool.

I don't know what the current status of mesher is. I'm still using a version that is years old, since no version I ever tried since back then ever worked for me. You can find the old trusty mesher here:
https://svn.wcjunction.com/utils/mesher
User name is "username"; password is "password".

is there a quick way you use to check if the materials have worked on the model effectively?, eg some kind of in engine ship viewer

Sorry if any of the above sounds a bit stupid :D
Not at all, I've been lobbying for a ship viewer for years :D
Just have to edit your savefile, give yourself your own ship, launch the game, then go to external view.
Last edited by chuck_starchaser on Mon Jun 30, 2008 1:58 am, edited 3 times in total.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

There are a several test missions in missions\test they load a bit faster than the whole game just to have a look at a model :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
rivalin
Bounty Hunter
Bounty Hunter
Posts: 153
Joined: Sun Jul 15, 2007 2:16 pm

Post by rivalin »

Wow, the devs must realllyyy hate artists :)

I tried the new and old methods, but the combination of all the possible errors (in the obj file, the mtl file, the xmesh, the BFXM, combined with the almost zero feedback from mesher+ the amount of time it would take to test whether it has worked in game = beyond my capacities for error avoidance and eye gouging frustration.

The funny thing is it seems like basic text stuff, so I can only imagine that it would take a programmer half an hour to knock up an app that would say "feed me an obj" "feed me a spec map" "feed me a diffuse map" -----compute---- "here is your BFXM"

I don't know, it just seems odd that of all the amazing coding that's been done for the game noone spent the time to get a remotely workable pipeline up and running. :shock:


I think I remember a thread mentioning decent tools as a target for the next release, so I might just wait until then. The thought of spending the next 4 or 5 hours trying to get it right only to have a small flaw found in the mesh or one of the textures and having to go through the entire conversion process again when the problem's been fixed is a too much :)

Here's the mesh as it is+the original textures and the outputted noodled textures, if someone with SVN access could upload it (just in case I forget about it) that would be much appreciated. I think for now I'll focus on contributing things that just require hitting the save or render button, maybe some cargo images or concept art.

http://www.box.net/shared/r9dpn5tesk

Thanks for all the help Chuck.
Turbo
ISO Party Member
ISO Party Member
Posts: 423
Joined: Mon Jun 11, 2007 11:54 am
Location: TX, USA
Contact:

Post by Turbo »

Chuck,

I actually understood most of that...scary. But, can you please copy posts like this into the Wiki, in a Advanced Texturing section or something? Then people will be able to find it when they need it, rather than hoping to stumble across it or remember the thread 6 months later.

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

Post by chuck_starchaser »

What part of it, Turbo? I thought using mesher was alredy in the wiki.
Or are you talking about the whole stuff of the past several posts?
I started writing a mega-tutorial on texturing, which I intend to finish after the shaders and the new pipeline are complete and merged into trunk.
After modeling a ship, what to do?
Once it's done I'll copy it to the VS wiki.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

Yeah, from what I have seen there is a total lack of good tools for realtime 3d artists to use for working on VS.

A mesh viewer would be great, then we could adjust things and see immediate results and then simply send all of our source files and in-game content to the code team to have to put in the game.

Or if there was an easy way to get things in game, it would take longer to see visual adjustments you've made to the mesh and textures, but optimization would be easier as you could see if a fleet of your ships on screen in an ordinary in-game situation slowed your system down at all.

Either way would be a huge improvement, let alone both. But until we see some tools like these, folks shouldn't expect any large quantities of high quality, completed models flooding into the project. Because with this lack of support we in the 3D art community are kinda flying blind here.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

chuck_starchaser wrote:What part of it, Turbo? I thought using mesher was alredy in the wiki.
Maybe he means your avoiding overdraw comments, the wiki doesn't have anything on that. I mean I think everyone knows it's something to avoid, but when they do need to cut some corners, they are not sure where exactly to cut them.

Like before I didn't know that it was rendered surface area or pixel count of the occluded area on screen that determines how much extra work it is for the gpu. I might have guessed it was the number of occluded vertices.

Also clarifing the comparitive inefficiencies of two separate meshes within the same model that are not intersecting versus those that are. Are they both considered overdraw, is the intersecting situation alot worse?

This sort of detail could be really useful, maybe in your how to weld howto.

(And that it looks like someone already added your info on creating diffuse, specular and shinniness maps on fendorin's archimedes thread to the wiki.)
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Deus Siddis wrote:
chuck_starchaser wrote:What part of it, Turbo? I thought using mesher was alredy in the wiki.
Maybe he means your avoiding overdraw comments, the wiki doesn't have anything on that. I mean I think everyone knows it's something to avoid, but when they do need to cut some corners, they are not sure where exactly to cut them.
I see; maybe I should write a wiki on mesh optimizations. Thing is, this is in the public knowledge, like here:
http://www.ericchadwick.com/examples/provost/byf1.html
http://www.ericchadwick.com/examples/provost/byf2.html
But I guess it wouldn't hurt writing a practical summary of do's and dont's.
Like before I didn't know that it was rendered surface area or pixel count of the occluded area on screen that determines how much extra work it is for the gpu. I might have guessed it was the number of occluded vertices.
Occluded vertices are yet another waste, but the thing is: There are two pipelines in a gpu: The vertex pipeline at the front, and the pixel pipeline at the back. The output of the vertex pipeline feeds into a small, hidden pipeline called the "triangle set-up" pipeline, whose output feeds into the input of the pixel pipeline; but we don't care too much about triangle setup here. The point is, whichever of the two pipelines runs slowly, it slows down the other. But as the years rolled by, the vertex pipeline got more and more powerful. Well, the pixel pipeline too; but not as much, because the pixel pipeline is hitting against a hard wall: memory latencies and bandwidth. So, it's very unusual for a mesh to be slow on the display due to too many vertices; most of the time it's the number and sizes of the textures, and pixel overdraw, that are the speed-bumps. This is not to say you can have a million vertices in every mesh, of course; but I'd worry much less about hidden vertices than about hidden texels.

EDIT:
A caveat: If the user turns on FSAA, then pixels crossed by edges have to be split into sub-pixels, so heavy meshes CAN increase (or rather DO increase) the pixel pipeline's workload, when anti-aliasing is turned on.
For a rough estimate, if you set FSAA at 4x4, that's 16 sub-pixels per each pixel split, so if your mesh splits 1/16th of the pixels on the screen, you've basically doubled the number of pixels to process. Unfortunately, I can't think of a simple rule of thumb to say how heavy a mesh would cause 1/16th of all screen pixels to be split, but avoiding excessive geometry is, of course, a good thing. Just not nearly as big a concern as overdraw.
Also clarifing the comparitive inefficiencies of two separate meshes within the same model that are not intersecting versus those that are. Are they both considered overdraw, is the intersecting situation alot worse?
No; intersecting is nothing special to a gpu; it gets resolved by z-buffering/testing (albeit z-fighting artifacts) during draw. The problem is that, unless you remove hidden surfaces in code (some engines do this, but it's hard), the gpu has no way of doing it for you. It draws ALL surfaces, hidden or not, and which surface covers which is decided by z-buffer comparisons, on a pixel by pixel basis, during frame draw. If you have many overlapping surfaces, the gpu will have to paint, or try to paint, every pixel on the screen where those surfaces overlap, multiple times.
Just to clarify, the gpu does cull about 50% of surfaces: those that face away from the camera. But this is easy to test (normal dot eye being positive or negative (well, it actually decides by clockwiseness of the vertices, but nevermind); so you don't need to worry about overdraw versus back-facing surfaces. But culling of front-facing surfaces based on coverage is something the gpu cannot do at the geometry level; it has to do it by z-testing pixel by pixel, while drawing to the screen.
This sort of detail could be really useful, maybe in your how to weld howto.
Ok, I'll try to put together a mesh optimization wiki.
(And that it looks like someone already added your info on creating diffuse, specular and shinniness maps on fendorin's archimedes thread to the wiki.)
Cool; that was probably Pyramid.

EDIT:
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, 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.
Thirdly, it should allow you to position weapons, subunits, engine exhausts and pilot.
Fourthly, it should allow you to move forward, to see if the ship's mesh orientation is right, and to change it otherwise (90 degree rotations).

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

Am I dreaming in 64-bit color? :D
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

Well organizing, updating, checking and centralizing information from various sources is a job of its own. Plus a mesh optimization tutorial can be useful for any free/open game project and it might dispel some of the myths about optimization and reveal some of the more technical secrets which might not be common knowledge.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

I'd like to comment something, but all artists resist the urge to read this as it will only confuse you people. This is technical stuff, intended audience: chuck. ;)

Now...

It's true what you say that usually the vertex pipeline is very fast nowadays and it's hard to encounter oneself in a vertex-bound situation (where the vertex pipeline slows you down). That's why people are pushing more and more computations on the vertex pipeline, like global illumination, particle physics, and many other cool stuff.

But it's also true that there are some situations where the vertex pipeline drops orders of magnitude in performance. That's:
  • Texture lookups in the vertex shader
  • Software skinning
  • Software emulation of the vertex shader (very common in onboard GPUs)
  • Stencil shadows
Three of those four cases are just cases where the GPU doesn't do anything vertex related and it has to be done by the CPU. Software skinning is inevitable if, for instance, you have to access the modified mesh (the skinned mesh) to do physics.
Luckily we don't use skinning, but if we ever did, we have to take that into account. Skinned meshes need to be either physically simple (don't use the skinned mesh to do physics) or low poly.
Lickily again, we don't do stencil shadows. Stencil shadows need complex edge detection and shadow volume extrusion that is usually done on the CPU. Not only they saturate the GPU's bandwidth because of the insane overdraw on the stencil buffer, but they also saturate the CPU with all that volume extrusion. Someone once did a shader that did shadow volume extrusion, which is cool, but still... stencil shadows look good but are evil.

What's not lucky is that other one: software emulation of the vertex shader. As I commented once, it already happens if you write your GLSL in a way the compiler doesn't like. Say, you run out of hardware registers to perform the computations. Instead of failing and saying "register number too high" or something like that, GL falls back to software emulation - sucker... onboard cards have a habit of always falling back to software. Perhaps they have merely formal hardware shaders (ie: useless with too little resources) that always fail to live up to expectations when pushed a bit hard, so the GL always ends up falling back to software. Or perhaps they simply lie: they say they have shaders and all they have is software emulation.

So... just that. Be careful with your shaders.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Well, I never liked stencil shadows, and wasn't sure why, but now I really know: overdraw. Good point! Yet another reason to add to the long list of arguments for using depth shadows (per unit).

Isn't there a way to disable emulation fall-back?

BTW, there should be a way to do rough inter-unit shadows in the cpu and communicate the data to the vetex shader, perhaps via a dynamic, monochrome texture that the vertex shader can use to modulate per-vertex diffuse color...
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

klauss wrote:Luckily we don't use skinning, but if we ever did, we have to take that into account. Skinned meshes need to be either physically simple (don't use the skinned mesh to do physics) or low poly.
With the port to OGRE I am not sure how this could even be a question, but skinning should definitely be on the road map.

A space game can technically get away with not having this, but trust me there is alot we could and would do with it when/if it is there--

Lots of moving parts beyond turrets for human tech (using full weighting between a part and a bone), organic motion for rlaan tech, organic motion for space lifeforms, organic motion for character communication, organic motion for sentient, domesticated and wild lifeforms within structures or (eventually) on planets, et cetera.


PS, why not use a high poly skinned mesh for rendering and a very low poly skinned mesh for physics?
Turbo
ISO Party Member
ISO Party Member
Posts: 423
Joined: Mon Jun 11, 2007 11:54 am
Location: TX, USA
Contact:

Post by Turbo »

chuck_starchaser wrote:What part of it, Turbo? I thought using mesher was alredy in the wiki.
Or are you talking about the whole stuff of the past several posts?
I was primarily referring to the "radiator physics" discussion, because of your statement about discussing it several years ago and deciding on an answer. But it's all useful if someone has the time and the skills to organize and post it.

Maybe I'm searching the wiki incorrectly, because a wiki search for "mesher" returns nothing. Then again, as I was writing this I got a crazy idea and searched the wiki for "ship" and also got zero results. :shock: So I am definitely doing something wrong.

Turbo
voice actor (with interest but limited skill in modeling, sound, video, & textures)
rivalin
Bounty Hunter
Bounty Hunter
Posts: 153
Joined: Sun Jul 15, 2007 2:16 pm

Post by rivalin »

Turbo wrote:
chuck_starchaser wrote:What part of it, Turbo? I thought using mesher was alredy in the wiki.
Or are you talking about the whole stuff of the past several posts?
I was primarily referring to the "radiator physics" discussion, because of your statement about discussing it several years ago and deciding on an answer. But it's all useful if someone has the time and the skills to organize and post it.

Maybe I'm searching the wiki incorrectly, because a wiki search for "mesher" returns nothing. Then again, as I was writing this I got a crazy idea and searched the wiki for "ship" and also got zero results. :shock: So I am definitely doing something wrong.

Turbo
voice actor (with interest but limited skill in modeling, sound, video, & textures)


Nope, the wiki is definitely busted, links to articles work but the search function is useless.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Turbo wrote:
chuck_starchaser wrote:What part of it, Turbo? I thought using mesher was alredy in the wiki.
Or are you talking about the whole stuff of the past several posts?
I was primarily referring to the "radiator physics" discussion, because of your statement about discussing it several years ago and deciding on an answer. But it's all useful if someone has the time and the skills to organize and post it.

Maybe I'm searching the wiki incorrectly, because a wiki search for "mesher" returns nothing. Then again, as I was writing this I got a crazy idea and searched the wiki for "ship" and also got zero results. :shock: So I am definitely doing something wrong.

Turbo
voice actor (with interest but limited skill in modeling, sound, video, & textures)
Ah, the problem of heat, and Meta-Black. Well, I don't know if that should be in any wiki. It's up to JackS whether he wants to set a standard that takes into account the need for heat radiation, and/or whether to adopt MetaBlack. I certainly would, but this is not my mod.

WRT the wiki; I never even tried Search, and I don't know much about how it is organized. My work on the wiki has been in the How-To's section, and I've seen Pyramid's work on like an entirely new wiki; but I only got there via links on posts; I'm not sure where it is via the main wiki page.

Perhaps the wiki needs to be indexed for searches to work. I don't know for sure, because at my websites I use a different wiki: DokuWiki; but I know that DokuWiki has a command in the Administration area for building or re-building an index.
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 »

I wasn't able to open the obj file in Wings3D neither convert it directly to bfxm with mesher. Could you post your original project file (blender?). When exporting to obj you may validate your obj file by running the command

Code: Select all

mesher_path/mesher V.obj V.bfxm obc
If you don't get an error the file should be fine.
rivalin
Bounty Hunter
Bounty Hunter
Posts: 153
Joined: Sun Jul 15, 2007 2:16 pm

Post by rivalin »

[Accidentally deleted by pyramid]
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 »

This one seems fine. I was able to view the ship in blender but that's about how far I've got for now.

Oops, sorry, I've accidentally edited your post instead of replying (that's the new layout of the buttons after loki has changed my permissions level). I'd appreciate if you could repost.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

i imagine there will be a few more :oops: pyramid i know i had a few myself till you learn the new additions.

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
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

loki1950 wrote:i imagine there will be a few more :oops: pyramid i know i had a few myself till you learn the new additions.
How many posts does it take, Admiral, before it becomes wrong? Hmm? A thousand, fifty thousand, a million? How many posts does it take, Admiral?

:P :D
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

Sometimes only one :lol: it's those Homer moments "Doh" that get us all we are human all prone to error besides it keeps the help desk monkeys in jobs :lol:

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
Post Reply