Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: Roanoke on March 02, 2006, 02:40:41 pm
-
(http://premium1.uploadit.org/magatsu1//lok01.JPG)
(http://premium1.uploadit.org/magatsu1//loki02.JPG)
-
YAY!
I love the look of the loki.
And this HTL version of it, looks very nice. :D
-
Well. The thrusters look a bit off, and I always thought the front of the side pods was larger than the backs.. but if you round off the head of the cocpit, underneath, a little more it'll be excellent. :yes:
My favourite interceptor.
-
Ooh. and this belongs in FSUP... So you know. :}
-
Not certain if the thrusters really should be proper cylinders (as apposed to triangular).... :doubt:
-
yeah the thrusters had stealth baffling that didn't work very well. It was kind of a defining feature of the design. but otherwise, YAY LOKI WITH COCKPIT!
Oh and if it doesn't make the poly count too high, I think the cylinders for the primary and secondary weapons would look cool with a recessed center to make them look more like tubes.
Final thought: do you want the pilot all the way back against the bulkhead or could he be moved farthur forward? A lot of FS fighters have such big glass areas that they seem like they could fit a jacuzzi and the pilot's cockpit under the glass area. I always thought this space went better behind the pilot than in front of him.
-
Excellent so far. :yes:
-
Nifty.
-
Isn't the cockpit supposed to stick out further then that? It looks like you compacted it a bit...
-
The cocpit bar is directly in front of his face in that pic... :blah:
-
...Is it just me, or is the cockpit a little... small. I mean, the Loki has always been the smallest fighter save the Pegasus, and that cockpit, namely the person inside, just looks damned small... could we see a comparison shot next to the Herc?
-
i think the human->ship scale is about right personally :)
-
****ing awesome :yes:
No complaints.
-
i think the human->ship scale is about right personally :)
I imported the HTL Perseus and scaled it to about the same size (just going off eye). If you compaire the two, the cockpit area for the Loki is way too big.
...Is it just me, or is the cockpit a little... small. I mean, the Loki has always been the smallest fighter save the Pegasus, and that cockpit, namely the person inside, just looks damned small... could we see a comparison shot next to the Herc?
I'll whip one up.
Oh and if it doesn't make the poly count too high, I think the cylinders for the primary and secondary weapons would look cool with a recessed center to make them look more like tubes.
Doubt if you'd notice when it's textured.
-
Oh wow. Sexy and beautiful. I'm getting excited with anticipation to see it in-game. :D
FEENEESH EET OR EELSE! :p
-
http://premium1.uploadit.org/magatsu1//compaire01.jpg - Max
http://premium1.uploadit.org/magatsu1//compaire02.JPG - FRED
Note the size of the Loki Cockpit to the Perseus.
-
Yeah, the Perseus cockpit is really small anyway. Not a bad looking upgrade (there are some things, like the winglets on the ends of the missile pods, that shouldn't be changed IMHO but they are fairly minor) and certainly quite welcome.
-
if it doesn't increase the poly count too much, i think the loki would look really good if you smoothed the main body and neck so it had more curved lines than boxy angles. i'm thinking the only reason the main body's got the boxy sharp angles was because of game and system restrictions. of course, i haven't seen any concept sketches of the loki, just my 2 cents.
-
should by angular, adds to the feel of the failed stealth project that its meant to be.
-
the Loki is spot-on IMO. :)
-
Final update before unwrapping & texturing:
(http://premium1.uploadit.org/magatsu1//loki03.JPG)
(http://premium1.uploadit.org/magatsu1//loki04.JPG)
(http://premium1.uploadit.org/magatsu1//loki05.JPG)
had to go on a serious low-poly diet. Down from >3000 to 2056. Still a little high but hey. Just hope the simple simon cockpit glass will cut it.
-
Oh, should I keep the Skull 'n' crosssbones in the texture ? I think it's silly as there's no reason for it to be there, but then it would be moving away from the :v: design.
the "mouth" at the front is staying by the way ('cos it looks cool, like on planes)
-
It's up to you whether you want to take that out or not. While it has been a predominant feature I have noticed on the Loki since I first started playing FS2, so has the "02" on the side of the Herc II. Don't take my word for it, but I think the work that you have done to update the model is all that matters.
BTW: is there a reason why you count down so much on the polys? I thought that high polys did not necessarily affect the frame rate of gameplay.
-
still needs to be as low as possible, especially fighters where there are lots of them about.
-
Single texture for fighters really is more important ultimately, but a poly budget isn't a bad thing to try to adhere to.
I'd say keep the skull, since the amount of crap I've taken over the '02' issue tells me that people really want the textures to stay consistant. It's usually covered by the insignia anyway (something else that people apparently still want) so unless you move the insignia to not be so huge (a good thing, IMHO) then I wouldn't move the skull.
And I still say the little ends of the pods should be pulled out to match the original.
-
I understand... excellent job! :)
As for the "02", I didn't bring that up to complain about it, only to use it as an example of a fighter which does not stay consistent with the original texture, which is not a bad thing. Sorry for any misunderstandings.
-
Yeah, the engine pod thingamaroos need to be pulled out. That's the only gripe.
-
thingamaroos
is that a technical term ? ;)
-
:bump:
Just wanted people to keep talking about the model, don't kill me cause you were expecting it to be done....
:headz:
-
Looks great....always liked the Loki despite it being fairly weak as a fighter. I sort of wish it got more use over just being a target. But a nice craft to do a full upgrade on. Definately paid off!
-
I always wondered how early the GTI had the Loki... could they have used it during the Terran - Vasudan war?
-
it was prolly used in Scouting/Raiding parties during the T- V Wars. they could have used it during a whole series of escapades but it's all classified and prolly destroyed.
-
Actually I just played the mission where they introduced the Loki, it apears to have been the newest prototype in a long study of stealth fighters technology.
During recovery of the Einstein's escape pods in Beta Aquilae, unidentified fighters attacked your wing. The results of our inquiry are puzzling-the vessels are Loki-class fighters, GTI design and manufacture.
GTI research and development created the Loki-class fighter at a top-secret installation, location undisclosed (The Jotunheim?). The prototype of a stealth fighter project, the Loki is designed to elude detection by all known sensor arrays.
-
Actually I just played the mission where they introduced the Loki, it apears to have been the newest prototype in a long study of stealth fighters technology.
During recovery of the Einstein's escape pods in Beta Aquilae, unidentified fighters attacked your wing. The results of our inquiry are puzzling-the vessels are Loki-class fighters, GTI design and manufacture.
GTI research and development created the Loki-class fighter at a top-secret installation, location undisclosed (The Jotunheim?). The prototype of a stealth fighter project, the Loki is designed to elude detection by all known sensor arrays.
Why newest? Prototype would, to me, just mean it was the first operational design they'd made with the various stealth concepts (etc) covered by their R&D project.
-
once this and the iceni are done, we really need a new set of mediavps !! :p
-
once this and the iceni are done, we really need a new set of mediavps !! :p
Don't forget the Ravana... :D
-
That's what I was thinking with the HTL Ursa, but these things usually come in waves, starting up and finishing up at ~ the same time.
-
About time too. The Loki is just simple enough to let you get really bored of the shape, but complex enough to make it a bit tricky to do. At last I can move on to either the Arcadia or Valkyrie!
Anyways, I've learned a ton of how to texture with this one - especially while doing the mechanical areas of the engines. I really like that technique. :D
Download - 2.5 megs (http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/HTL%5FLoki%5F1.0.rar)
For the newbies, to install it simply extract the files using WinRAR, place the .pof file in Freespace2\mediavps\data\models, the .dds files in Freespace2\mediavps\data\maps and the .ibx file in Freespace2\mediavps\data\cache.
Note: I have NOT included the cockpit textures - those can be found in the HTL Zeus package since they've not been changed further. It DOES have an insignia that appears to work, but I turned it off for the pics.
Onto the piccies:
(http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5F1.jpg)
(http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5F2.jpg)
(http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5F3.jpg)
(http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5F8.jpg)
(http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5F7.jpg)
If you add "show ship" to the Loki's flag list in the ships table, this is what you'll see:
(http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5FCockpitView1.jpg)
And a couple of other images:
Extra Pic 1 (http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5F4.jpg)
Extra Pic 2 (http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5F5.jpg)
Extra Pic 3 (http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5F6.jpg)
Cockpit View 2 (http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5FCockpitView2.jpg)
And finally, an old & new comparison, because the old one really sucked:
(http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/LokiHTL%5FComparison.jpg)
If you find any bugs, lemme know ASAP - since the next MediaVPs are around the corner, we really need this thing to be in perfect health for them.
And there you have it. Enjoy. :)
-
Great work, downloading now :yes: :yes:
Please, before you start another model, could you make an animated glow for your Lucifer? (I also posted it here (http://www.hard-light.net/forums/index.php/topic,41374.msg953818.html#msg953818)).
-
Excellent material as always VA :nod:
-
Yay! Shiny new toy!
*Goes off to find the HTL Zeus, muttering "How did I miss that one?"*
-
WOW Excelent
-
very nice!
could you do a new (better) HTL myrmidon oder HTL ulysses next plz? ^^
-
very nice!
could you do a new (better) HTL myrmidon oder HTL ulysses next plz? ^^
:yes: that would be cool :pimp:
-
hey! a HUD panel with an alpha channle! nice work!
too bad adding show ship invalidates my multi stats....
-
Awesome work :yes: I really, really like your greebling style (and am copying it shamelessly ;) )
-
SW33T!!!
*recommends to INFA*
-
YES YES IT IS OUT wOOt.
-
Very nicely done. A major enhancement to one of the most common craft in FS2! :yes:
-
too bad that idiot GTVA command never lets you fly it.
-
Great work! I love the smooth edge on the cockpit. ;)
-
Beautiful work! Now it really looks like an advanced recon fighter!
-
Wow just Wow i always liked the look of that ship, even though its stats make it a little unpopular, but that looks real nice
-
Wow. Pure. Sex.
-
Amazing work! Can't wait to see it in game... *downloads*
-
Great work! :yes:
-
Seeeeexy
Downloading now
-
I came.
-
Very nice :yes:
-
I came.
some people really creep me out on these forums....
:rolleyes:
-
I came.
some people really creep me out on these forums....
:rolleyes:
Yeah couldnt agree more :nervous: :nervous:
-
Crikey, thanks all. :)
So no bugs thus far? If so, that just has to be a first for me. ;)
Please, before you start another model, could you make an animated glow for your Lucifer? (I also posted it here (http://www.hard-light.net/forums/index.php/topic,41374.msg953818.html#msg953818)).
I'm going to have to hesitantly say no at this stage sorry. Firstly it's a 2048 res map that suffers greatly at lower res, and even at 1024 you're talking a massive memory footprint for such a simple effect.
Also, it doesn't look like support for fancy texture effects is all that far from being implemented or at least implementable at the modder level in FSO.
And finally it's a heck of a lot of work which would require skill I probably don't have to do well and time I definitely don't have ATM. :(
could you do a new (better) HTL myrmidon oder HTL ulysses next plz? ^^
Heh, unlikely on 'HTLing' the HTL Myrm, but it's a 'possibly' on the Uly - maybe sometime in the post Arcadia, Poesidon, Valkyrie, Athena and Centuar future if it's still not underway. I think it's been started at least twice before though.
Awesome work :yes: I really, really like your greebling style (and am copying it shamelessly ;) )
Oooh really? Awesome. :D Any aspect in particular?
-
Awesome work :yes: I really, really like your greebling style (and am copying it shamelessly ;) )
Oooh really? Awesome. :D Any aspect in particular?
Well, I'm talking about the way you go completely nuts with greebling, but keep the individual greeblie parts very simple (mostly box-like), which keeps the overall polycount within reasonable limits. Your pirate base thing is a prime example of what I mean.
Also, you seem to pay attention to keep the "greebling-resolution" roughly the same over the whole model, which should be the goal for every high-poly model. Sadly, there are quite often models with high polycount, which have very detailed parts and big flat parts side by side (which doesn't look good IMHO).
Ok, enough brown-nosing for today ;)
-
VA, excellent work, first of all, you made the cockpit look good ;). Second of all, it looks very nice and black..
and go for the valkeyri
-
DROOOOOOOL
-
Oh em eff gee, someone finally finished it.
That thing looks awesome, VA. Awesome work as always. :):yes:
Now do the Ulysses :D :P
-
What about the Athena? One of my favorite bombers in FS1.
(the only bomber I really liked because it was in the FS1 OEM pack which I played through about six times)
-
The Athena was finished, dude. By either Trashman or Turambar.
-
nebuala trails are a bit off with the model. thats all.
-
wasnt me, ive only been modelling for a short time now
-
Awesome model. This better be going into the next vp release. :D
-
Your mom will be available. :P
Looks purty. At ambience 0 and looking at the dark side of the fighter it really does look like a stealth fighter.
Did he use the stock Loki for LOD01?
-
i think doing that is kinda standard.
and no_emissive_light + amient_factor_0 is the defaults [v] would probably use if they had 256mb gfx cards. but they didnt. so retail had no lighting.
-
ah, nice.
-
Loki looks pwnsome, very, very nice. :cool::yes:
Now... do the Valkyrie ASAP!
EDIT: Oh snap! 8) doesn't change to sunglasses anymore.
-
The Athena was finished, dude. By either Trashman or Turambar.
It was Trashy. And no offense to him, but that model wasn't too hot.
-
Great model. :yes: Works with FS2_Open for MacOS X without a problem :D
-
nebuala trails are a bit off with the model. thats all.
Those are defined in the table file, which I didn't want to touch. ;)
Would be nice if it could be fixed sometime though.
Did he use the stock Loki for LOD01?
...Sorta. It's the original loki, but remapped it to use the new textures so it should look better than the stock one.
As for what is next on the list - finishing the Valkyrie is indeed next:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Valkyrie/ValkWIP3.jpg)
I'll be redrawing the textures again though, so don't expect it any time soon. :p
Well, I'm talking about the way you go completely nuts with greebling, but keep the individual greeblie parts very simple (mostly box-like), which keeps the overall polycount within reasonable limits. Your pirate base thing is a prime example of what I mean.
hehe, thanks, but the pirate base thing isn't really a good example of keeping polycount within reasonable limits to be honest. :nervous: (It does suit the 'completely nuts' part quite well though)
-
:eek2:
That Loki is already pure sex, but...I think I will love you until the end of time when you release the Valkyrie.
In a purely platonic and non-stalker-ish way, of course.
-
What pirate base?
-
The Athena was finished, dude. By either Trashman or Turambar.
It was Trashy. And no offense to him, but that model wasn't too hot.
None taken.. It's not as detailed as other HTL models out there (when it comes to polycount). Still, it turned out nice :D
-
Any chance of you redoing it? :)
Gah, we shouldn't be talking about the Athena on a Loki thread...
-
The Athena was finished, dude. By either Trashman or Turambar.
It was Trashy. And no offense to him, but that model wasn't too hot.
I wouldn't call it Trashy.
It was 'alright', as in it didn't bring that much more to the model.
I think he's a mediocre modeller (even that's something few actually aspire to), with an extreme preservance that can only be admired. IMHO if he could 'outgrow' his 'box'-modelling, he would be ranked among the top modellers of HLP, alas he's only among the top modders so far.
(Once again IMHO).
-
I agree. TrashMan has a few good models (like the Whitehall...) but they aren't all that hot at times.
-
id give everything for an HTL sathanas.
-
What pirate base?
My favourite model so far. Mainly 'cos it's just pure greeble-fest. ;)
(http://sectorgame.com/ti-file-dump/VasudanAdmiral/SpaceBall1-WIP1.jpg)
(and before anyone asks it and I'm then forced to hurt them: No. The above pic is not of a complete texture. :p )
More about it (http://www.sectorgame.com/forums/viewtopic.php?t=2125)
The Athena was finished, dude. By either Trashman or Turambar.
It was Trashy. And no offense to him, but that model wasn't too hot.
I wouldn't call it Trashy.
It was 'alright', as in it didn't bring that much more to the model.
I think he's a mediocre modeller (even that's something few actually aspire to), with an extreme preservance that can only be admired. IMHO if he could 'outgrow' his 'box'-modelling, he would be ranked among the top modellers of HLP, alas he's only among the top modders so far.
I think he's just saying it was Trashman who made it there - not saying the model was 'trashy'. ;)
But yeah, the truth is; he didn't change much at all from the original model. Added a CP (though according to modview it doesn't work because there's no texture applied to the glass), some recesses to existing polys and a couple of bevels. There are a few other small changes - but again they're more 'differences' than detail. Every other HTL model done thus far has had a lot more detail than that. :(
-
Now that is a fierce-looking Loki... all that darkness makes it a lot meaner than the old one.
On TrashMan's models... well I'll agree that they can be just "meh..." and uninteresting sometimes, but I don't mind. I'm happy with his Athenas as they are (thank goodness I kept backups of my hackfixed version on FileFront - I think I lost the copy on my HDD).
-
When I started work on the Athena I actually started on the Mk2, not the original (and made the model from scratch, didn't edit the original one). I deliberately kept the polycount down below 2000 for multiple reasons:
1. I don't see the benefit of 5000 polys fighters. They look nice, but I won't be looking at large, well-lit renders in game.
2. I got lots of friends with poor rigs. How many here play FS2 with everything set to high?
3. Going too overboard with the polys tends to disrupt the canon look sometimes, with ppl adding stuff that isn't there on the original, which is something I try to avoid when possible.
All in all there's nothing stoping me from making a 100000 poly Athena.
However, I won't for now...Now capships - having lots of well-used polys there is a must. That's why the Archy and Whitehall cross the 10000 treshold.
-
2. I got lots of friends with poor rigs. How many here play FS2 with everything set to high?
Seconded. My previous computers were all... shall I say, terrible. :(
-
1. I don't see the benefit of 5000 polys fighters. They look nice, but I won't be looking at large, well-lit renders in game.
There are a lot of opportunities to see close-up, well lit fighter.
2. I got lots of friends with poor rigs. How many here play FS2 with everything set to high?
I do. And I don't care about the rest, nobody is forcing them to use all the bells and whistles. In fact, saying "I've got 10 years old hardware, so you people with faster computers can't have better gfx than me" is... Well, you know.
-
As for modelling it out after the plate lines... I just cant do it, and Ill explain why
Look at the HTL Zeus for instance... It has lots of polygons following the plates of the texture. The end result is a waste of polys given the fact that in the future, you will have bump maps and the sort in freespace (yeah im faithfull :P).So in sum, whoever modelled the Zeus (cant remember who), will have to redo it once we have bump maps, when he could have modeled a bit more into the ship, instead of following everything by the letter.
But for now I guess we can deal with 2000k poly fighters. (hehe 2million polys)
Uh oh I think I see VA browsing the board... :nervous:
AND IN HIS THREAD TOO!!!!!! :eek:
-
As for modelling it out after the plate lines... I just cant do it, and Ill explain why
Look at the HTL Zeus for instance... It has lots of polygons following the plates of the texture. The end result is a waste of polys given the fact that in the future, you will have bump maps and the sort in freespace (yeah im faithfull :P).So in sum, whoever modelled the Zeus (cant remember who), will have to redo it once we have bump maps, when he could have modeled a bit more into the ship, instead of following everything by the letter.
But for now I guess we can deal with 2000k poly fighters. (hehe 2million polys)
Uh oh I think I see VA browsing the board... :nervous:
AND IN HIS THREAD TOO!!!!!! :eek:
Yes - big very texty post alert. :p
And whoever said that is kinda wrong. Bumpmaps are not always a good substitute for actual geometry, and I've given careful consideration to what I will and will not model in, because I know they're around the corner. In fact I have bumpmaps lined up for the Triton (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedTriton.jpg), Aeolus (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedAeolus1.jpg) and Lucifer (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedLucifer1.jpg) already (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedLucifer2.jpg)!
Bumpmaps accentuate existing detail - they do not and should not replace it.
As such I won't have to redo the Zeus (and why can nobody ever remember me? :wtf: ), because the bumpmaps will only serve to improve the detail that is already there. Here's a question too: What are all these things I could have modeled in instead of the level of detail that I did make? There's simply nothing else to add in it's place except the exact detail that bumpmaps really should be used for - which is smaller than what I did add.
So please go squish that notion in whichever internal forum you read it in. :p
When I started work on the Athena I actually started on the Mk2, not the original (and made the model from scratch, didn't edit the original one). I deliberately kept the polycount down below 2000 for multiple reasons:
1. I don't see the benefit of 5000 polys fighters. They look nice, but I won't be looking at large, well-lit renders in game.
2. I got lots of friends with poor rigs. How many here play FS2 with everything set to high?
3. Going too overboard with the polys tends to disrupt the canon look sometimes, with ppl adding stuff that isn't there on the original, which is something I try to avoid when possible.
All in all there's nothing stoping me from making a 100000 poly Athena.
However, I won't for now...Now capships - having lots of well-used polys there is a must. That's why the Archy and Whitehall cross the 10000 treshold.
You've used those arguments before now - when pretty much the same points were leveled at you, but they simply don't hold water. I am going to systematically pull them apart now because I'm quite certain they are primarily what is limiting you: (well that and I'm kinda just rehashing stuff that's going into the Blender tutorial anyway ;) )
1) As this Loki should prove to you, even the smallish details in your model will be visible in game (all those 'well lit renders' on the first page are just the Loki in the ship lab. In game.) Whether it's mid-dogfight, in the techroom or in the Lab - the lighting really does make even small details pop out. They don't even have to be the kind of detail you'd notice as detail, but rather the kind you would miss very much if it wasn't there.
And people really do notice if that detail just isn't there, else there'd be no point at all to HTLing the fighters/bombers. Why are there no recent 'beauty shots' of the retail fighters anymore? Simply because the HTL stuff looks better in-game, and that's what people prefer to look at. 3d modeling for games is as much a form of art for people to enjoy as any other type is. We don't build the models and draw the textures just to represent a ships position and shape now do we? We build them to capture the feel of that ship.
As such, let loose with as many polys as you need to capture the feel of a ship, because there's very little point in a ship that can run on low end machines if it's unimpressive as an artwork in itself. Even ships that are not meant to be good looking in shape need to be well built to capture that ships 'feel'. You can't for example make a dodgy model of a freighter and justify thay by saying it's meant to look ugly. It needs to look real first. ;)
Basically, go for looks first while keeping the polycount in mind - not the other way around. Aim for the image you have in your head, rather than what you think your or others graphics card can cope with, which leads us to the second point:
2) This is the reason that holds least water. First and foremost, Taylor has written up that excellent set of guidelines, tips and explanations in the stickied thread up the top of this forum. And in fact - I'd guess that this Loki would run faster than the HTL Athena based on the textures used. You've used PCX for both the hull and the cockpit, which is going to take up more memory and run slower than DDS DXT1s would. It's not the polycount that matters anymore - it's the textures.
Look at this:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/230k_Polys.jpg)
Not terribly impressive eh? Well actually it is. That there is 230 000 polys in game in a single model, rendering with a shinemap no less! Now granted it wasn't with a terribly good framerate (20 or so), but the point is, the game engine is fast enough to take high polycounts without skipping a beat if they are used properly.
Note that by 'properly', I mean not only pay attention to format and reducing the number of textures, but also use the features like lods and detail boxes. That way the detail only becomes visible when it really is visible.
And on top of that, as Wolf says, it's better to have a full detail model that some of the lower end computer people have to turn down the graphics for now than have a low poly model that you'll need to upgrade again a year or so later because it looks so out of date. ;)
Again, don't limit at the artwork level what should be limited by the end user.
3) This is probably the most valid point, but it's still kinda invalid. If you're making something better to the point where it disrupts the canon look (something you personally might not want), the answer is not to add barely any detail at all, because you're not really making it any 'better' in the first place!
No; the answer, as in point 1, is to make it look as you want it too look. That is, if you want it to totally keep the canon design feel, then you model it to do that.
As some have noticed, I keep my HTL stuff as strictly close to the canon look as I possibly can, which is for a couple of simple reasons:
1) I really like the canon designs and want to keep them like that. If I want to add my own stuff, I'll build my own ship.
2) It's more of a challenge to be inventive within the restrictions of canon - and I like such challenges too. :)
3) 100% guarantees people will accept it in place of the original. Least important of my reasons, and it's also me just being a bit of a wuss. I wouldn't like it at all if I put all this work into a model upgrade, only to end up with something that no-one uses for that role. Having a model that is too dissimilar to be considered an upgrade and too similar to be considered a different ship would kinda suck. What it takes to be considered 'too dissimilar' will differ greatly from person to person though.
And finally, while I'm here, there's also a very VERY important technique related aspect that you could try: surfaces. I'm not talking about smoothing - that's just a poor substitute for actual detail in the majority of cases, and it really does show in the final result. :\
What I'm talking about relates to the whole modeling technique/mentality used. The idea is that polygons form surfaces, and then surfaces form ships. If you build your ship out of surfaces rather than polygons then you will almost always end up with a far superior result visually - because it will look built rather than modeled. Take the Loki or the Zeus as an example of what I mean.
There are no or VERY few polygon creases/edges on the model that are not fully intended to be there from a design perspective. There are no hull plates that abnormally bend over any such intended crease either. The head of the original Hecate was a prime example of this, as are many of the low poly original [v] models.
Creases and ugly geometry that simply would not be constructed on the ship in the real world have no place in the model of that ship. ;)
Anyways, enough from me. I really should do some of that whole 'study' thing for uni. :\
-
BTW VA, sorry to go OFT but do you still have a copy of your HTL Uglies fighters that I can appropriate? I lost my copy... :(
Thanks in advance. :)
-
As for modelling it out after the plate lines... I just cant do it, and Ill explain why
Look at the HTL Zeus for instance... It has lots of polygons following the plates of the texture. The end result is a waste of polys given the fact that in the future, you will have bump maps and the sort in freespace (yeah im faithfull :P).So in sum, whoever modelled the Zeus (cant remember who), will have to redo it once we have bump maps, when he could have modeled a bit more into the ship, instead of following everything by the letter.
But for now I guess we can deal with 2000k poly fighters. (hehe 2million polys)
Uh oh I think I see VA browsing the board... :nervous:
AND IN HIS THREAD TOO!!!!!! :eek:
Yes - big very texty post alert. :p
And whoever said that is kinda wrong. Bumpmaps are not always a good substitute for actual geometry, and I've given careful consideration to what I will and will not model in, because I know they're around the corner. In fact I have bumpmaps lined up for the Triton (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedTriton.jpg), Aeolus (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedAeolus1.jpg) and Lucifer (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedLucifer1.jpg) already (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedLucifer2.jpg)!
Bumpmaps accentuate existing detail - they do not and should not replace it.
As such I won't have to redo the Zeus (and why can nobody ever remember me? :wtf: ), because the bumpmaps will only serve to improve the detail that is already there. Here's a question too: What are all these things I could have modeled in instead of the level of detail that I did make? There's simply nothing else to add in it's place except the exact detail that bumpmaps really should be used for - which is smaller than what I did add.
So please go squish that notion in whichever internal forum you read it in. :p
Actually it was me who made that post in an internal board. Post which I hold my point to it: when I see platelines referenced in the original model texture, as a new, extremely small bevel, that is barely noticed (that is, easily simulated by bumps), I have to say it is a bad a HTL attempt IMO.
True they dont add detail, but accentuate them... but thats exactly what you do in most of your HTLizations of V's models. And most of the detail you accentuate, could easily get away with a bump map. And thats my point. In fact, if you take a look at modern games models, you will see the truth of what I say :P
As an answer to your question, what you could have done on any htlization job, was to improve the design of the ship, instead of making a carbon copy of the original, but with more polys. But obviously thats my way of seeing things on the HTL stuff: the Hecate, Ravana, Moloch, Aeolus, Orion, etc, are perfect examples of what I mean. They still feel like what they should be, but they also have something new to their design.
And thats what IMO should an HTL design be all about: take the original and spice it up with more goodness (goodness= more stuff). If people dont like your original traits at first, try again, and they eventually will, and accept them as good replacements of the originals
Dont get me wrong, I think you are actually a very good modeler (and I did know you modeled the Zeus, but I didnt want to rise names on that discussion, as a matter of respect). But I just simply cant agree at HTLizing stuff, where rigourously (sp?) nothing is added to the originals, and even less, I cant agree that for a game, no matter how many polys it holds, people make every bit of detail into a bevel, which is completely unnecessary.
-
3. Going too overboard with the polys tends to disrupt the canon look sometimes, with ppl adding stuff that isn't there on the original, which is something I try to avoid when possible.
But changing the Zod weapons in FS1 so that they fire faster is perfectly alright :confused:
-
In fact I have bumpmaps lined up for the Triton (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedTriton.jpg), Aeolus (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedAeolus1.jpg) and Lucifer (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedLucifer1.jpg) already (http://sectorgame.com/ti-file-dump/VasudanAdmiral/Pics/BumpmappedLucifer2.jpg)!
...
...
...
...
...
*dies*
-
Bumpmaps are not all-powerful. They cannot simulate the majority of detail that I model, because they are not going to look as good as having actual geometry there will.
Eg: the underside of the Zeus is the area I presume you mean most, because the top has very little of it:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/ZeusUnderside.jpg)
That detail sticks out in modview and it sticks out in game - more than bumpmaps would in the same position. They just can't represent paralax like that and I've always been able to pick out what is and isn't bumpmapped. Being geometry they may also eventually cast shadows, further separating them from bumpmaps.
I stick to canon because of the reasons I stated above - primarily because I like canon. Only in cases like the aeolus, triton and TC-Tri where canon offers almost nothing to go by will I spruce it up. Where that is not the case, there is no need to. As I said, if I want to add my own stuff, I am perfectly capable of building my own ship.
I upgrade these ships as much for myself as I do the community, and if for example I took the Zeus and put (for the sake of the argument cool looking) pipes between the weapon pods, you might accept those additions, but I wouldn't. I'd see it as a Zeus with pipes between the pods.
I can quite happily accept people making changes to the ships they upgrade (within reason obviously), but I cannot accept them if I make those changes myself without good reason.
So if you'd rather see and make new things appear on ships where they weren't before, by all means do so! However that's not going to change the way I do it. :p
-
I meant both the underside and upper side, as well as the pods (the missiles most notably). Theres lots of greebling there that would look just as good with a bump map (and a well done one). The only reason you can always pick out what is and whatsnot bumped is simply because you know where a bump map would do the same thing as a mesh, and you suppose that the game devs are smart enough to realize it :P
True they dont represent parallax like that, but then again, for a fighter sized ship, that is moving at a quite fast speed, you wont be seeing any parallax at all.
Take a look at this:
(http://www.unrealtechnology.com/screens/character_creation3.jpg)
thats an ingame mesh... wanna see the the wireframed version?
(http://www.unrealtechnology.com/screens/character_creation2.jpg)
Thats 5k polys (most of them are in the face area, for obvious reasons)... see how much the bump maps add to it? see how many detailing (small details) it saved the mesh from? And you can also see how the lightning reacts flawlessly with them as well (obviously we dont have that kind of lightning on FS yet). THAT is a good bumpmap job, and it does what im saying pretty well, if not perfectly.
And im not telling you to NOT stick to cannon... im just saying that if you are, theres no reason to turn a game fighter into a sculpture, in order to make it HTLized.
In fact, if people want to zealousy to keep cannon by 100%, then the way Trashman handled the Athena would be the way to go IMO
-
I think that one has been generated from a very high poly mesh - it's way beyond what bumpmapping alone can do and so not a fair example.
A couple of hundred extra polys - even a thousand or so are not going to harm performance if the model is efficiently made and well lodded, so what reason do you have to say that detail shouldn't be added? In fact, what if it's easier to make that detail with geometry than it is with a bumpmap? It looks better than it would otherwise now, and can only look even better when bumpmapping comes along - at very little cost to performance.
And your comment about zealously sticking to canon is uncalled for. There's an important difference between enshrining every poly of canon and just wanting to keep the feel of the ship the same. I prefer to keep that feel the same, you prefer to add or change some things. I don't mind either, because there is nothing wrong with either approach - they are just different.
The results at the end of the day are that we end up with a higher quality model for the job. Does anyone else here see a problem with that theory?
-
IIRC that mesh uses normal mapping, which is quite a bit more powerful than plain bump mapping.
-
It does use a high poly mesh yes... to generate the bump map in Z-Brush (which is the same as a normal map btw :P), and nothing else. The high poly mesh is just a reference for a 3d modelling program, nothing more. The game itself only uses that mesh I showed above+textures.
That was just to prove my point that well done bump maps DO produce the same results (on practical terms) as minor greebles
And like I said, I dont mind sticking to cannon, and im not saying that is a wrong aproach. Im just saying that people in general have a tendency to turn ships into greeblefests, which is uncalled for in a game.
And you can show me pics about the game engine supporting a bazillion polys in spheres that have the same texture, but we both know thats not how things go practically. Practically, you will have several different types of ships on your screen (more different textures), weapon\engine effects flying around, etc.
-
We might as well have the best quality we can until bump mapping and normal mapping are available to us. When that happens, you can all optimize from there, remove some polys here, insert a bump map there. Focus on right now. I say we're fine as we are now.
-
The point of that 230 000 poly object pic is to show that polycount is not a particularly problematic area for FS these days. You've been saying that adding all the detail that's on the Zeus and other ships is unnessecary because well done bumpmaps might be able to do it just as well - and perhaps they might.
However, when you weigh up the relative performance costs of a reasonably sized bumpmap and a reasonable count of a few hundred/(thousands even) extra polys, I think the extra polys will come out as a much more efficient way to get to that level of detail than adding a bumpmap will. :p
Using the example of being in game - you want to replace the relatively pronounced geometric details on the Zeus with a bumpmap right?
Well, aside from the fact that this large bumpmap will be far more of a detriment to performance than the geometric detail was (even when it's not on-screen it's being stored in memory), it will only be able to represent smaller detail than the geometric stuff did. As such, it has even less visability in-game, and so by your own reasoning, there's no point in having the bumpmap either, and therefore no reason to have removed that geometric detail in the first place! :p
What I reckon should happen is that those people with machines that can run with full detail in-game, should - and also should be able to get the full benefit from that. High res textures, high poly models, capped off with a purdy bumpmap. For those without such fancy hardware, they can just lower the settings a notch or two.
Provide as much of a greeble fest as you like, and let the user decide how much they want to see. Reasonably good future proofing in a way. ;)
-
Well, aside from the fact that this large bumpmap will be far more of a detriment to performance than the geometric detail was (even when it's not on-screen it's being stored in memory)
What I reckon should happen is that those people with machines that can run with full detail in-game, should - and also should be able to get the full benefit from that. High res textures, high poly models, capped off with a purdy bumpmap. For those without such fancy hardware, they can just lower the settings a notch or two.
Provide as much of a greeble fest as you like, and let the user decide how much they want to see. Reasonably good future proofing in a way. ;)
I can't agree enough. From the standpoint of a FreeSpace gamer, my 1GB RAM system chokes on FSO. I am against anything that increases the game's RAM consumption. Video card strain on the other hand? Ha...bring it on. I couldn't care less about video card polycount strain (GPU processing, that is). But eating my system memory and me ending up swapping bump maps to disk? Hell no. The less swap file usage this game takes, the better. My poor hard drive's already dying >_> --- BTW, I use a Radeon 9800 Pro 128MB in case you were wondering
-
However, when you weigh up the relative performance costs of a reasonably sized bumpmap and a reasonable count of a few hundred/(thousands even) extra polys, I think the extra polys will come out as a much more efficient way to get to that level of detail than adding a bumpmap will. :p
Using the example of being in game - you want to replace the relatively pronounced geometric details on the Zeus with a bumpmap right?
Well, aside from the fact that this large bumpmap will be far more of a detriment to performance than the geometric detail was (even when it's not on-screen it's being stored in memory), it will only be able to represent smaller detail than the geometric stuff did. As such, it has even less visability in-game, and so by your own reasoning, there's no point in having the bumpmap either, and therefore no reason to have removed that geometric detail in the first place! :p
Not all the detail in the Zeus is unnecessary, like I mentioned before. What adds to a general shape is more than welcome, and in fact efficient. The problem is those smallish details that are minimal\secondary... that is teh relatively non-pronounced bevels. THOSE small bevels are the issue, and ive stressed it well enough I believe, so please dont hiperbolize on what I say :P
And my reasoning is exactly what you described, with one catch: you mentioned shadows before, mentioned that a bump map wont be able to produce them (which is true), but that on the other hand the polygon details will (true as well). What your forgetting is that when we have the shadows, you will see how much performance will suffer just because you have all those smallish bevels casting shadows all over the place (shadows which btw, would be minimal and barely visible, if at all, that is, redundant)... something that wouldnt happen in the case of using a bump texture, which makes it a much more viable option performance wise. And in the ned, it would have the same visability in-game as having those polys, in practical terms.
Everyone on the gaming industry chooses bumps over poly detail, no matter how harder it is to generate those bump maps, and thats for a reason: creates the best visual quality\performance balance.
And about the user choosing what he wants to see in-game, thats an utopy imo. The user can choose which type of textures to render (glows, specs, bumps, etc), he can also choose the LODs he wants to see. However he cant choose what each LOD comes with. If you take for instance the Loki (which IMO, is better than the Zeus, on the issues im defending). If the user has bumpmaps available to him (that would simulate many details perfectly), so he doesnt need the current LOD0, he is stuck with the LOD1 that is the FS retail (that is, although he gets rid of those tiny details that the bump map can handle, he is also stuck with that non-perfected shape that misses the refinement in shape that LOD0 has). Note that by shape, I mean the overall form and "motion" of the object in question.
-
At the moment the issue is polys vs bumpmaps - shadows are way way off, and so shouldn't really be introduced here. And even then, if it becomes an issue, they can be turned off or can use a lower LOD pretty easily.
And where are you drawing the line between unpronounced and pronounced details?
The smallest ones I can see are the shallow recess on the underside of the neck and the missiles sticking out of the pods - those are where I could get away without as much detailing as I did use, and if I were to redo the thing now then I might do just that.
All the rest though is pronounced enough to become quite visible in-game when the specular light hits it. Perhaps when we see what bumpmapping can and cannot do in the FSO engine we can make a better distinction, but as is, I see very few bits of geometry that could be done via bumpmap. Even then, the parts that could be bumpmapped instead are simply not going to harm performance.
About the user-defined performance - they have complete control over the model detail slider in game. That controls at what range the lods will switch around, so they'll only ever get the highest detail when it's close enough to be seen.
Also, what kind of a detail selection would that example be? :p
The retail loki in LOD1 with added bumpmaps I am quite sure will take up more memory and render more slowly than the HTL loki without bumpmaps - so switching off bumpmaps would be a far better choice for gaining performance than using LOD1 and would look better as well. :p
-
Yes shadows are way off, but you DID mention them as a means of justifying those details...
The line im drawing is perfectly visible in the pics Ive posted above... the armour plates and details arent modelled in, just the overall shape. Im sure you can deduce from that what is unpronounced in the Zeus.
That also explains the kind of detail selection I was talking about.
And yes, obviously the LOD1+bump maps would be more performance hindering than the HTL Loki... in fact, on a same note, obviously every single game dev company is doing everything wrong because you are not... :rolleyes:
To be honest im pretty tired of having to discuss circular logics, so from my part this discussion is over. Time will prove me right.
-
Well look - you've made your point, and I won't model in details as tiny as the ones I have been on future fighters. However my point that bumpmaps will be more of a performance drain than that detail is still valid. You are talking a couple of hundred extra polys vs an entire bumpmap. It's just no contest.
The bottom line is simply that we give them the lot, and the end users will pick what they do and do not want to see. It needs no further discussion.
-
Err, it's all well and good going on about how bumpmaps will save the world, but ladt I checked we didn't have bumpmaps yet. So the current equation is:
More polies = more detail right now + more accurately rendered detail forever + less performance strain + less memory usage
vs.
Bumpmaps = more detail at some as yet unknown point in the future + less accurately rendered detail (accurate in the sense of how it behaves, shadows and parallax and whatnot) + greater performance strain (everyone should know by now a few hundred or even a thousand polies makes practically zero difference to performance in the FSO engine) + greater memory use.
I really don't see the contest.
As for the argument that you wont see the very small detail, well, 90% of the time you're right. But when you do see it, say a small edge on an indent somewhere catches the light and shines, or a flipping fighter gets a bumped face lit on three sides in sequence, it looks good. Really good. Definitely worth the very, very minor increase in GPU load, with the only real cost being an increase in construction time, and since VA's building these anyway, surely that's his own time to "waste"?
-
Hey! BW! Where've you been mate? It's been aaaaages. :D
Hmm, I think your custom text....kinda... answers that question actually. ;)
-
WEll..compeling arguments, there's no question about it.
Tis not the problem of making more detailed ships - the question is when is it enough? 1000 polys? 2000? 5000? 10000? 1000000?
My only concern is to make the ship look good - if textures can convey that good enough (depends on what you consider good enough tough) then I won't bother adding greebling. If hte models is such that it requires 100000 poyls to look good, then I will use each and every one of them.
Maby it's just me, but I consider relatively flat surfaces EFFECTIVE in tearms of ship design. Having openings every 2 inches and open pipes and wires sticking everywhere on a armored warships jsut doesn't look right ot me. (altough it may look nice).
but then again, this all varries from design to design and what you want to convey with it...
-
Maby it's just me, but I consider relatively flat surfaces EFFECTIVE in tearms of ship design. Having openings every 2 inches and open pipes and wires sticking everywhere on a armored warships jsut doesn't look right ot me. (altough it may look nice).
but then again, this all varries from design to design and what you want to convey with it...
Seconded. If you need ventilation, put a grill there (like for example over a modern tank engine compartment).
-
That's where it mainly depends on personal taste.
See, I like seemingly unnecessary greeblies. They look cool (which is the more important reason), and second, they give the viewer a better sense of scale of the big ships.
-
Yes but were talking about fighters here... on big ships the matter is entirely different (you actually get to SEE those greebles once in a while, not to mention you gain a better sence of realism when you fly trough them... so in fact those greebles arent "unnecessary"). On fighters however its pure redundancy
More polies = more detail right now + more accurately rendered detail forever + less performance strain + less memory usage
vs.
Bumpmaps = more detail at some as yet unknown point in the future + less accurately rendered detail (accurate in the sense of how it behaves, shadows and parallax and whatnot) + greater performance strain (everyone should know by now a few hundred or even a thousand polies makes practically zero difference to performance in the FSO engine) + greater memory use.
I really don't see the contest.
Your completely right... right now. Hopefully in a couple of years we will have more advanced graphics available to us on FSO: besides the already mentioned bumpmaps, we will have shadows (which we already had, but were dropped because of (ahah) performance strains because of (ahah) too many polys casting shadows...), more advanced and efficient lightning, etc.
You are overly concerned with the memory use of textures atm... Im concerned with render issues of overquantity of polys in the near future. So if im getting it right, since right now more polys are the only way to get detail, even if redundant, we keep with it, and in the future we remodel our ships? Ok, if you are all willing to go trough it all again, dont let me stop you.
And yes, right now a few thounsand polys make practically no difference in FSO. However, in some (if not many) missions you wont have just a "few" thounsands more in front of you. You may have a 2 or 3 fighters right in front of you, then some freighters\transports a bit farther away, etc. Do the maths, and that will exceed a few thousands. And this happens all the time, especially in escort missions (which arent few).
Oh, and buying another Gb of Ram is actually cheaper than buying a new processor and FX card... much cheaper.
I really dont see the contest.
Of course you can all jump at me, because im thinking too far ahead, and that im being too wishfull of our SCP team, and fact is I am. Ive done it before, and they proved my faith was well placed (for those that dont remember, I was already doing HTL models, before the SCP team was seriously thinking of implementing it in game. Again, defending that we would be able to use more polys in the future, despite everyones "bickering"). So yeah Ill gladly keep this gambit. :P
-
well, when that day comes, we'll just use our really nice high-poly models to generate normal maps for the somewhat lower poly models.
-
(looks between VA and Raven...
...
...
...Sighs at another debate)
Guys, chill out. Your both right. Good texture work can save the use of polys, but conversely, a detailed model gives it that realism.
Personally, I side with VA, being a modeller first and a texturer a distant second. Plus any way to avoid having the pc grind to a halt as it struggles to juggle several huge textures is good.
'Bump mapping' sounds like it can add an extra layer of realism, but to me it needs the high quality model as a base. So, lets cool our turbos, and praise VA for his absolutely brillient model work. Raven pulled that Ravana out of the bag (BTW, that fixed yet?), so we all know how good you both are.
Ah, sudden idea. VA does all the Terran stuff, and Raven goes over the Shivans... should help set them even more apart... ;7
-
I really shouldn't have declassified that post... :nervous:
-
I wanted to reply point-by-point to this, but no doubt the post would be far too long, so I'm just going to summarize things (sort of). VA has already asked my opinion on this and I'm going to give some of that same info here as well as add a few new points...
You have to remember that almost all the work at optimization has gone into the texture side of things, both in rendering performance and memory usage. It's not really going to be any better than it is now, and is in fact going to get much worse. Remember that normal maps aren't easily compressed, since the compression utterly destroys quality in the case of a normal map. That means most/all normal maps are NOT going to be compressed. Adding a normal map like that to a fighter is going to, in the best case, more than double the memory requirements for that model. Normal maps are going to comprise from anywhere to 65-80% of the models texture memory requirements. That is a complete killer considering the already extremely high memory usage that we already have from textures. All of the work that can be done to improve memory usage has already been done, there isn't much more that we can get out of it. And memory usage is only going to increase in the future. Shaders require memory, new animations require more memory, more explosion types require more memory, render targets require more memory, FSAA requires more memory. And we also have possible future support for light maps and height maps which is also going to increase memory usage that much more. Memory usage is our killer, it's only going to get worse, and everyone has to not only realize that but also plan for it.
A normal map is also not the same as any other map since it requires much more processing work to render. It means per-pixel lighting, and that costs GPU performance, and it also requires more CPU time to compute the tangent space coords for each and every object that gets rendered, every single frame. A diffuse/glow/spec map, combined, cost about as much performance as adding a normal map. It does add more realizism, but it most certainly is not coming free, even if you exclude the large memory requirements. A normal map isn't going to add much in the way of detail to a fighter than an extra 1-2k of polys will. The difference is that using the normal map will actually be slower than going with the extra polys. So don't depend on normal maps to save you from anything, because they won't. They will add extra detail to a model, but if it's not on a large ship then that is going to be wasted memory and wasted processing time. Shaders will allow more efficient use of normal maps, but it's not going to do anything for the memory usage. For every normal map that you add you are taking something away, whether that be better explosions or more weapons effects or whatever, it's going to cost you.
I gave VA some basic poly counts that I want to see in any current fighter and bomber. Those in the 8-10k range for fighters, and 9-12k for bombers. My counts for larger vessels are up in the air, but I fully expect 25-40k to be the norm before long. I mentioned already that optimizations have been done to increase the performance of texture handling, but almost nothing has been done for geometry yet. There are numerous areas in the model rendering code which are creating bottlenecks. The collision detection code is also rather crap with regards to large poly models. Object culling and render order are also something that is horribly wrong with the code. These are things that are going to get fixed. Even if the hi-poly models are a little bit of a strain now, future code upgrades probably won't even flinch at them. I already use 60k+ models for testing, so handling large poly models is possible even with the current code. And it is only going to improve. Vastly.
We can always tie in better detail control to allow users to tone down the poly hit if needed. But what we can't do is take a lower-poly model and make it look better later on. Use textures efficiently and creatively, and then increase poly counts. We added the code to handle textures better, but the biggest problems are in the model rendering and collision detection code. Once we work those issues out the performance should increase significantly. So plan ahead and give your models that extra 2-3k of poly detail now (provided it's not wasted obviously) and the code will catch up to it. Even your basic video card these days can easily handle the poly counts that we are using, it's the code that has trouble, but that we can do something about.
Go with the the larger poly counts, texture your models efficiently, use detail boxes, avoid poly waste, avoid using normal maps unless it truely adds to the model. These are all basic things that should not only improve the model overall, but also improve how that model works in-game. Lighting will be enhanced with more polys, texture mapping (if done properly) will be enhanced with more polys, and general "coolness" will as well. If you are making a model now then you might as well plan for the future, because we are. We are planning for more models in a single frame, and more efficient collision detection, and more efficient rendering, and much improved user detail control. If you only make your model for what you can do now then you are only hurting yourselves, because in another year those models will be low quality in comparison to what you will be able to get away with.
-
You didnt mention what kind of effect shadows would have on performance though
@Raptor: no the Ravana isnt fixed yet as far as I know... which is a good thing because I plan to go back to it and change some stuff here and there and make debris for it (sames gonna happen to the Hecate).
-
You didnt mention what kind of effect shadows would have on performance though
Assuming that we ever get shadows you mean? :D
If it's done right then the extra polys shouldn't have much, if any, affect on shadows. We can also just use a lower LOD for rendering the shadows anyway, since LOD1 should be near identical visually to LOD0, but without all of the little details. But we don't render for shadows the way that things are rendered normally, since we can skip a lot of detail that isn't going to show up in the shadow map anyway. I have still never seen the code that Bobboau did for shadows the first time, and it's possible that we can do a more efficient job of it if it's a bit more API specific anyway (there are about a half-dozen ways to do great shadows quickly in OpenGL for instance).
Adding support for shadows isn't even on my todo list though. There are far more important, and impressive, things to work on instead.
-
You hit the wound there, finally.
since LOD1 should be near identical visually to LOD0, but without all of the little details
Which so far, they arent. At the moment their just the FS retail ones, without any kind of shape optimization, which makes them look bad. Otherwise all this debate couldve been avoided
-
Remember that normal maps aren't easily compressed, since the compression utterly destroys quality in the case of a normal map. That means most/all normal maps are NOT going to be compressed.
Compressing normal maps should be a runtime option for those who are low on memory, but want fancy effects and don't mind the artifacts.
That is a complete killer considering the already extremely high memory usage that we already have from textures. All of the work that can be done to improve memory usage has already been done, there isn't much more that we can get out of it.
Well, no. The animated glow textures currently have 37 frames, that means there are 37 textures used for single animated glow effect. Most of the glows have just 2 key textures (sometimes 4) and the rest of the frames are different blends of the key textures. By using some little scripting that will control blending on the GPU, we can keep only the key textures and throw away all the intermediate textures.
A normal map is also not the same as any other map since it requires much more processing work to render. It means per-pixel lighting, and that costs GPU performance
I'd be worried about GPU performance with per pixel lightning on the first geforce, but that's in the past.
and it also requires more CPU time to compute the tangent space coords for each and every object that gets rendered, every single frame.
Tangent space needs to be computed only once, preferably when the model is exported to freespace's model format.
-
Compressing normal maps should be a runtime option for those who are low on memory, but want fancy effects and don't mind the artifacts.
If it's TGA then it will be compressed with -img2dds. But we aren't going to add another option for it. If the files are uncompressed DDS then they would be left that way.
Well, no. The animated glow textures currently have 37 frames, that means there are 37 textures used for single animated glow effect. Most of the glows have just 2 key textures (sometimes 4) and the rest of the frames are different blends of the key textures. By using some little scripting that will control blending on the GPU, we can keep only the key textures and throw away all the intermediate textures.
With shaders perhaps, that that isn't a valid option at the moment and won't be for everyone regardless. That also only accounts for glows, not for all of the effects which are truely what counts for most of the memory usage. In the grand scheme of things glow maps aren't that big of a concern.
You currently need a 256-512 meg video card to take full advantage of the new MediaVPs. That is just sad, and it's only going to get worse as time goes on. It's been proven time and time again that memory usage can not be managed properly by the community. If you use shaders to cut down on the number of frames in a glow map, someone will just make that many more animated glow maps and you'll be right back where you started. There is no win here, regardless of what you do. We've been through this enough times already to not even bother trying any more.
I'd be worried about GPU performance with per pixel lightning on the first geforce, but that's in the past.
It's slower than a regular map regardless. The point was that using a normal map over more polys isn't necessarily going to give you anything. In fact, it could actually be slower.
Tangent space needs to be computed only once, preferably when the model is exported to freespace's model format.
Tangent space coords are computed on model load. But they then have to be converted to UV coords every frame for each vert of every object. There is going to be a performance hit from that.
-
You currently need a 256-512 meg video card to take full advantage of the new MediaVPs. That is just sad, and it's only going to get worse as time goes on. It's been proven time and time again that memory usage can not be managed properly by the community. If you use shaders to cut down on the number of frames in a glow map, someone will just make that many more animated glow maps and you'll be right back where you started. There is no win here, regardless of what you do. We've been through this enough times already to not even bother trying any more.
Ok... the memory usage is pretty high, but I still think it's ok
The current high-end standard is 512-640 MB gfx ram. Even low-end cards already have 256MB nowdays.
FS2_open never looked bad. It was always close to the more recent games. Even thouh FS2_open still looks great, we've fallen quite a bit behind.
Current-gen games need way faster PCs, than FS2_open, featuring pixel shaders an normal mapping.
One thing why FS2_open still looks nice, are the high-res textures. In texture sharpness, it's superior to Doom3 and imho also to Quake4.
We can advance to normal mapping, and whatever maps needed by some shaders, without having to worry about eh diffuse and the specular maps.
I know normal maps will increase the memory load a lot. Especially if we can't find a good way of compressing them. But if a player has a 128MB gfx card, he can still disable normal mapping.
I doubt the copmuting problem is as bad as the memory one.
Memory is the bottleneck in our case. In that case... we can use more polies, right? I know that will need a tiny bit more ram too, but we still got some room for more here, if the memory usage is the bottleneck anyway.
Aiming for a more high-end audience. What do we have all these nice options to disable things for anyway? And you also don't have to use the advanced effects VP.
What I think is, that we should try to go for a reasonable high visual quality, but also give players the options to optimize the game, so it can be used on older PCs too.
The textures sure aren't too big compared to modern games. Ok, the effects still might beat most current-gen games in memory usage... ;)
(yeah guilty...)
-
With shaders perhaps, that that isn't a valid option at the moment and won't be for everyone regardless.
This doesn't need shaders, however they would help.
If you use shaders to cut down on the number of frames in a glow map, someone will just make that many more animated glow maps and you'll be right back where you started. There is no win here, regardless of what you do.
That's surely a win, because we'll get more animated glow maps :)
Tangent space coords are computed on model load. But they then have to be converted to UV coords every frame for each vert of every object. There is going to be a performance hit from that.
Uhm. To clear things up: tangent and bitangent vectors are calculated once and are used along with the normal vector to create matrix, which is used per vertex to transform light and view vectors to tangent (uv) space.
-
I know normal maps will increase the memory load a lot. Especially if we can't find a good way of compressing them.
High end ati hardware supports 3Dc normal map compression. Nvidia's G70 and better emulate this extensions by transparently using V8U8.
For older hardware, there's some research done at http://developer.nvidia.com/object/bump_map_compression.html (http://developer.nvidia.com/object/bump_map_compression.html), but it probably requires shader support, so that's no go for even older cards, which usually have less gfx memory, which makes things even worse.
-
The current high-end standard is 512-640 MB gfx ram. Even low-end cards already have 256MB nowdays.
FS2_open never looked bad. It was always close to the more recent games. Even thouh FS2_open still looks great, we've fallen quite a bit behind.
Current-gen games need way faster PCs, than FS2_open, featuring pixel shaders an normal mapping.
I've got a 128 meg card. We also have to support hardware which isn't desktop grade, and may only have 128 or 64 meg available. There simply aren't enough people with cards like that to warrant requiring more than 128meg. Even Doom3 can work well with 128 meg cards. You have to turn down the effects detail, but it still works quite well. Our options in that department are very limited though. This is also why I use and maintain my own set of MediaVPs, I can tailor them to work well with 128meg cards and not have to sacrifice the things that I care about in the quality department.
But also remember that FSO is an old engine. We've upgraded parts of it, but only parts. It still does many things in a horribly inefficient manner, which makes the system requirements go up just as if it were a current-gen engine. As we add more features those problems only increase and performance will only decrease. There is only so much upgrading that can be done before it's no longer FreeSpace, and I'll leave the project before we ever get to that point.
Uhm. To clear things up: tangent and bitangent vectors are calculated once and are used along with the normal vector to create matrix, which is used per vertex to transform light and view vectors to tangent (uv) space.
Yeah, I think that's what I said. I know how it works, I coded support for it. :)
High end ati hardware supports 3Dc normal map compression. Nvidia's G70 and better emulate this extensions by transparently using V8U8.
We aren't going to support 3Dc though, at least not unless NVIDIA adds support for their older hardware as well. And we probably aren't going to support anything that can't work without shaders. I've only seen the use of these formats with shaders, which eliminates them as options. Anything that I can figure out how to use without shaders is what I'll add support for.
-
Define whats no longer Freespace?
-
I've got a 128 meg card. We also have to support hardware which isn't desktop grade, and may only have 128 or 64 meg available. There simply aren't enough people with cards like that to warrant requiring more than 128meg. Even Doom3 can work well with 128 meg cards. You have to turn down the effects detail, but it still works quite well. Our options in that department are very limited though. This is also why I use and maintain my own set of MediaVPs, I can tailor them to work well with 128meg cards and not have to sacrifice the things that I care about in the quality department.
Very valid point. If we go for ultra quality, most of the players won't be able to use all maps/effects, or have to lower the options, but of course, that might look worse than optimized content for non-high-end PCs.
However... in one or two years many players will probably have updated their PCs already... and can take the maximum quality settings FS2_open offers without any problems. And have the power to do even more, but can't use it.
Imho you can optimize FS2_open very well anyway. I'd start with disabling env mapping (yeah that would be painful for me), then normal mapping and least specular.
And I'd seriously start to forget about the 64 MB gfx card users. I can't improve the FS2 content, without upgrading it.
If they don't have enough memory for the high-end features, they simply can't use them.
There is a limit for textures though. I know there are a lot of textures, that could actully still look good in a smaller version. And other models that use gigantic textures, like the landscape in SoL. But only for now... as I intend to use a detail texture for it, as soon as that is possible.
But also remember that FSO is an old engine. We've upgraded parts of it, but only parts. It still does many things in a horribly inefficient manner, which makes the system requirements go up just as if it were a current-gen engine. As we add more features those problems only increase and performance will only decrease. There is only so much upgrading that can be done before it's no longer FreeSpace, and I'll leave the project before we ever get to that point.
Sure, FS2 is old. If it was only about the tech, I would probably work on something for a current-gen engine. ;)
Well, even though some things could be faster, I think FS2_open performs very good. I takes lots of polygons. And using detail boxes, even more. It worked just fine on my GF 4 TI. Even some of the crazy stuff I made of SoL. ;)
Anyway, I love the technical advance of the engine. As well as the new HTL models.
When there's nothing left of the original engine, I'll probably be gone too.
-
Define whats no longer Freespace?
Working to the point of a completely rewritten engine. I'm not here to reinvent the wheel. I'd rather work on Ogre3D, TGE, or something else instead if that was the case. The goal is basically to upgrade the engine and allow more/better support for mods and TCs. Yes, that will mean adding normal map support, and shaders, etc. But features are prioritized on a upgrade basis, or at least the ones from me. If we scrap the graphics and redo that code to be up-to-par, and also do the same for AI, and physics, etc., then we are technically writing a new engine bit by bit. It's no longer FreeSpace at that point, regardless of whether it were still "compatible" or not. The soul would have been ripped out.
I'm not going to work towards making it on par with current generation game engines like Doom3 or the new Unreal engine. That's too much work, and has already been done (or is being done) in about 3 other open source projects, ones that we could actually get paid to work on. I haven't spent countless hours and fixed 700+ bugs just to make a new engine. I'm here because I love what Volition did, and I don't want it to end. It's not the content that makes FS great, it's the heart, and when that's gone, I will be too. :)
-
Well calling the heart of FS the code lying underneath it is a kind of biased opinion now isnt it? :P
-
I haven't spent countless hours and fixed 700+ bugs just to make a new engine. I'm here because I love what Volition did, and I don't want it to end. It's not the content that makes FS great, it's the heart, and when that's gone, I will be too. :)
Agreed. The (new) content keeps is alive and well-known, but isn't the heart of FS2.
I'm not going to work towards making it on par with current generation game engines like Doom3 or the new Unreal engine.
Well... as soon as it has normal mapping and shaders, FS2 will be pretty much on par. Actually, we've reached a 'pretty much everything is possible" state then. It's up to the projects to make good use of the features. (Maybe also to optimize the performance a bit ;) )
And imho, the tools are pretty good. So it's not too hard to create "cool" stuff. ;)
-
Sure, FS2 is old.
It's not 50 yet, is it?
(http://www.area51zone.com/aircraft/sr71_high.jpg)
-
Well calling the heart of FS the code lying underneath it is a kind of biased opinion now isnt it? :P
The "heart and soul" being Volition, which is both the code and original campaign/universe. It's a package deal. I mean, there are things like the Homeworld 2 FS2 mod, which brings FS2 to Homeworld 2, but it's not FS2. You can't port FS2 missions to Ogre3D for an engine and still have it be the same thing either. I work on this project for FS2, not for SoL or BtRL or WCS... for FS2. It's apparent that the mods like it as well, since if they didn't they would quickly move to another game engine. But they recognize the "heart", and are willing to take advantage of it to bring that same magic into their own works.
Volition just created this strangely magical mix of fun and turned it into a game. The fact that we are still here proves that. It's a phenomenon that's seldomly replicated, and not understand. It's always risky screwing with something that you don't understand. :)
-
Wow, you make it sound so much like a relgious experience. That we are on the path to enlightenment and salvation. Amen brother Talor! :D
-
Okay... I just have a little OT question:
taylor said that the geometry code can be a bottle neck.
Well... Since february I have a new Graphics Card. A GeForce 7600 GS. It's WAY faster than my old GF3. Even on my outdated system that could/should be bottlenecking this card.
But in FS2 I have a little fun-mission that starts with four colossus-class ships.
The Colossus really isn't a high-poly model, but the four colossus-ships are enough to drop the Framerate to around 23 FPS.
Other ships that arrive after them (even high-poly ones) are way "FPS-friendlier". The FPS only drops a bit when they arrive.
Is this a FS2-Problem or could it be a combination of problems? Or is it just "normal"?
Oh yeah... Some informations ;)
1. The FPS is the same on OpenGL (Linux, in Windows OpenGL doesn't work anymore because my CPU don't have SSE :( ) and Direct3D (Windows)
2. I only gain a bit of FPS if I disable all FSO-Features. Even using retail-FS-stuff isn't gaining this much (up to MAXIMUM 40 overall-FPS).
3. I don't know anymore how fast the mission was with my old GF3... I think around 18 FPS but I don't know... (EDIT: I looked at "old" Screenshots and it seems that it was 23 FPS without other ships. But new ships and especially effects like beams and explosions did have a much greater FPS-impact)
4. Enabling Anti Aliasing doesn't seem to have any impact on FPS...
-
Under the media VPs, the Colossus model uses six 512 res textures, a 1024 res and two 64 res textures. There are also 90(!) subobjects over the whole thing, and 13 of those turrets use two textures each.
Polywise it only has 1924, so that's not the problem. My guess is that it's the switching between the textures over the main hull and all the subobjects that causes the slowdown. A properly optimised HTL one with good use of detail boxes and textures will almost definitely outperform it. ;)
-
Under the media VPs, the Colossus model uses six 512 res textures, a 1024 res and two 64 res textures. There are also 90(!) subobjects over the whole thing, and 13 of those turrets use two textures each.
Wow... That's much... But like I said: Even WITHOUT the MediaVPs it's still "slow" (MAXIMUM 40 FPS if all FSO-Features are turned off as well).
Polywise it only has 1924, so that's not the problem. My guess is that it's the switching between the textures over the main hull and all the subobjects that causes the slowdown. A properly optimised HTL one with good use of detail boxes and textures will almost definitely outperform it. ;)
Well... Some people began with it, but AFAIK no one ever finished it till now...
Let's hope that it will get better ;)
-
I know - I remember when Karma began it ages ago ;) (in fact THE Phreak recently rediscovered it for himself here. (http://www.hard-light.net/forums/index.php/topic,46788.0.html))
Also, it wasn't so much the size of the textures I was refering to there as it was the number of them. 9 textures is a lot of switching to do - especially over 90 objects. Neither number has changed between retail and the media VPs, so it's no wonder that it happens with or without them. :\
-
Okay... For everyone who wants to look at the fun-mission I mentioned: Here it is!
But beware! Nonsense and a crazy lightshow inside :D
(contents of ZIP: mission-file and two modular tables for the beams)
[attachment deleted by admin]
-
To summarize what was said.
Using more polies right now is better becasue:
- Since using another texture takes another render pass and more computation, using more textures is just plain bad from a performance point of view.
- Adding more polyons rarely invokes another render pass, so it's efficient for the time being.
- Apparenlty polyon rendering is actually a bottleneck so it can be improved..
- High polygon models using less advanced 'DX9 generation' features are easier to render on a variety of cards/machines as the engine already has very advanced LOD (level of detail) tools (like detail boxing).
- A high polygon model is easier to optimise/upgrade later by implementing 'DX9 generation features' than the other way around.
-
What's with the stupid formatting of doom? :wtf:
-
Using more polies right now is better becasue:
Nobody said that. It's not that simple. Using a normal map can save a huge ammount of polies. Just keep in mind that normal mapping can't do everything. It might be even completely useless for some models.
What I think is, that we're too much worried about polygon counts and don't care that much about map sizes.
-
To summarize what was said.
Using more polies right now is better becasue:
- Since using another texture takes another render pass and more computation, using more textures is just plain bad from a performance point of view.
- Adding more polyons rarely invokes another render pass, so it's efficient for the time being.
- Apparenlty polyon rendering is actually a bottleneck so it can be improved..
- High polygon models using less advanced 'DX9 generation' features are easier to render on a variety of cards/machines as the engine already has very advanced LOD (level of detail) tools (like detail boxing).
- A high polygon model is easier to optimise/upgrade later by implementing 'DX9 generation features' than the other way around.
You did know that FS2O uses OGL and not DX... right?
-
Using more polies right now is better becasue:
Nobody said that. It's not that simple. Using a normal map can save a huge ammount of polies. Just keep in mind that normal mapping can't do everything.
Anyone mind telling me what normal mapping is? the only thing i know is that its great for some reason.
-
Anyone mind telling me what normal mapping is? the only thing i know is that its great for some reason.
hi,
normal mapping is a variety of bump mapping.
the most developer use normal mapping to visual reconstruct geometry.
so you can have a modell with 5 oder 10k of polygones, but the normal texture let it look as it had over 30 or many more polygones.
farcry was one of the first game, which it has use it.
one of the problems of normal mapping is, thats its only visual.
on the shapes of a modell, you still see that its hasnt so much polygones.
but if you have to render a lot of geometry, then its very helpfull.
a other of the probelms are the shadow / point of view problem.
if you have a bad angle to the texture, you see thats its only a texture and no really geometry, because its look flat.
thats problem solve first virutal displacemapping or parallax mapping.
but aside of the problem i think normal mapping is a good tool to improve the visual details of modells.
Mehrpack
-
Anyone mind telling me what normal mapping is? the only thing i know is that its great for some reason.
It's an auxiliary map which uses just two channels (Red & Green for example). This channels are not colour info but the X & Y component of the normal vector to the surface in each pixel. In this way the GPU can simulate roughed surfaces over the flat polygon surface, because the illumination from a direction will reflect with different direction (and therefore intensity from your point of view) in each pixel.
It's a way of adding more detail without using more polygons. It's very useful to model small detail (the roughness of a stone, skin wrinkles, wires over the ship, bolts ...). Many 3D recent games use it. Although it adds more render work it allows much simpler models. Each modder has to find the balance in each situation.
An advanced version is parallax mapping where the pixels are also slightly displaced. This version can create nearly 3D effects with just a flat surface. (FEAR uses it, for example, shot damage on the walls are flat maps although they seem really hollow. You need a DirectX9c GPU).
-
It's an auxiliary map which uses just two channels (Red & Green for example).
Three channels.
An advanced version is parallax mapping where the pixels are also slightly displaced.
This is not an advanced version, but completly different effect.
-
It's an auxiliary map which uses just two channels (Red & Green for example).
Three channels.
Nope, just two. As the vector has a value of one, you don't need to tell the z component. z=Sqrt(1-x^2-y^2)
An advanced version is parallax mapping where the pixels are also slightly displaced.
This is not an advanced version, but completly different effect.
Well, more or less. I know this isn't an expert explanation but speaking in a home way about this kind of 3D effect over a 2D surface, the evolution would be:
1st generation. Bump mapping
2nd generation. Normal mapping
3rd generation. Parallax mapping
-
Wow. This is like reading the bridge column in the newspaper except you know that there are some people who understand it.
-
Could you send me the uncompressed maps VA?
I'd like to kill some of the 8-Bit leftovers on the maps. ;)
Maybe even the PSD for some new kind of map. If you didn't do that already.
-
Err, for the base map? None of the 8bit leftover stuff should be visible on Lod0, and barely any of it on Lod1, where it shouldn't matter anyway.
I'll upload the .pspimage or the bmp files if you want though?
-
Oh it looks good, minus the fact it's made out of rock..
The Zeus looks the best so far.
edit: ok the Hasp. looks the best, but thats a capship :P
btw is there a problem with the Ravana? When I switch to no diffuse mapping, I get odd lighting issues, like the light is coming from the wrong place.
That's because the Loki normal map in the 3.6.10 beta isn't the awesome one Vasudan Admiral made that's way back on page 1 of this thread. For your convenience, here's the link (http://www.freewebs.com/twisted-infinities-va/HTL-Loki/LokiHTL-normal.zip). No made of rock problems with this one!
-
I have to agree that I don't like the Loki's 'bumpy skin' too much. The other normal mapped details on it look good though.
And the model itself is of 1st class, of course :)
-
Anything you'll see on a fighter will probably look cartoonish at best.
More than likely the normal mapping will be completely invisible. :(
The 3.6.10 media vp's disagree with you.
Re: these three statements, I agree with BlackDove -- I've been replaying the entire retail campaign with 3.6.10 mediavps. when a loki flies past me at full speed during a dogfight, it's true that it is moving too fast to see every little detail -- but there is beyond a perception that what is flying past me is a very highly detailed ship -- the normal maps DO have a not insignificant impact on the appearance of fighters during high-speed combat.
The dev team has taken things in a really good direction. I've been playing this thing for about a year now, and it has never looked better.
-
I suppose if you have only indentation (which i usually do) then pure white background (pre-normalizing) works best, if you have only bump outs then pure black background (and white detailing) works best, if you have both then grey (128,128,128) gives best of both worlds.
I will agree with VA on one thing, height maps on fighters just isn't worth the performance hit
-
More than likely the normal mapping will be completely invisible. :(
Re: these three statements, I agree with BlackDove -- I've been replaying the entire retail campaign with 3.6.10 mediavps. when a loki flies past me at full speed during a dogfight, it's true that it is moving too fast to see every little detail -- but there is beyond a perception that what is flying past me is a very highly detailed ship -- the normal maps DO have a not insignificant impact on the appearance of fighters during high-speed combat.
Oi, taking me out of context there a bit. :p I'm talking only about subtle normal maps like the one Scooby has just made for the.....um.....well I have no idea what it's called - the pinkish orangey fighter thing. If I wasn't looking for it, I wouldn't be able to see the normal map at all, let alone notice the detail on it in a dogfight.
I suppose if you have only indentation (which i usually do) then pure white background (pre-normalizing) works best, if you have only bump outs then pure black background (and white detailing) works best, if you have both then grey (128,128,128) gives best of both worlds.
I will agree with VA on one thing, height maps on fighters just isn't worth the performance hit
Huh? No - again I'm talking ONLY about subtle normal maps. Heightmaps are used to enhance and strengthen already strong normal maps, and normal maps really are worth the performance hit if they are strong enough show up as they do in the MVPs. Dial up the contrast on your source heightmap for the spikey fighter thing and regenerate the normal map so that the bumps on the plates are about as visible as they are on the following loki image and see how that looks. If it does look good, keep it. If not, there's no point in using a normal map for that fighter at all.
Anyway, since apparently people don't seem to like the slight texture on the lokis normal map, here's the new version where the roughness has been removed, and I fixed a couple of other things I forgot about in the previous one too.
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/NormalMapping/NewLokiNormalMap.jpg)
Download: http://www.sectorgame.com/ti-file-dump/VasudanAdmiral/FSU_Fixes/NewLokiNormalMap.zip (Might need to copy+paste the link)
Oh and as for the 'level' ground to use - IF you intend to create a heightmap to use in conjunction with the normal map, ALWAYS try and use grey on the heightmap - even if you're doing all extrusions or all indents. Herra is spot on. Using a non-grey colour as your 'middleground' on a height map will create really weird map distortions. For example, if I use my loki source map as a height map, I get this:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Loki/Loki_Height.jpg)
Notice the weird and silly looking texture shifts around the edges - the game is treating what is supposed to be middle ground as an indent and shifting everything accordingly - because in my source image the middleground is nearly black.
If you don't plan on using your height map in-game, then it doesn't matter. :)
-
Does this help? :P
(http://img.photobucket.com/albums/v356/Shodan_AI/ratoth1-normal.jpg)
-
That looks to me to be the same map. :p
Showing what it looks like without the diffuse & spec map is fairly useless, because as the previous pic demonstrates; that particular map is close to invisible.
Seriously, try making a much stronger one with deeper indents for the plate seams. This is what the source map for the loki looks like:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Loki/LokiHTL-height.jpg)
From there I use crazybump on full normal map intensity, full power to fine, medium and large detail, and 0 to very large.
-
Something like this?
(http://img.photobucket.com/albums/v356/Shodan_AI/screen0034.jpg)
How do I get it so the isn't such a huge gap between the plates? It looks like you could drive a truck through it.
-
I'd need to see the height map to be able to tell more accurately, but I suspect you just need to use thinner lines. How are you making them currently?
-
Off may main map, they're simple 1px lines.
edit: OHhh I think I got the solution, in crazybump, set intensity, fine detail, medium detail to 99, set large and very large to 0.
-
VA: I _already_ had a problem shooting at the loki's. Kept ramming into them. Now I don't even want to do that.
They're the enemy, dangit! You make it too hard to blow them up.
(In other words, really dig that new normal map. Must be in 3.6.10 IMO.)
-
lol, well glad you like it. It should be in the upcoming MVPs. :)
Scooby: Can you post the source heightmap?
-
Here you go: http://img.photobucket.com/albums/v356/Shodan_AI/ratooth-bump.jpg (http://img.photobucket.com/albums/v356/Shodan_AI/ratooth-bump.jpg)
Also setting medium to 66%, large to 33% and verylarge at 0 also works too.
-
Oh, I didn't realise the Loki in the beta VPs was different to the page 1 release. I still had those ones installed. I actually prefer that original to this new one, but yeah, the one in the VPs was definitely too much.
-
The loki map in the betas is the same as the one first page of this topic. The one I've just posted is a modified version of that same map that has a few minor fixes, and no texture roughness to it. :)
Scooby: Here's what I changed it to:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/NormalMapping/ScoobyHeightMap.jpg)
And here's the normal map I get when using the same crazybump settings as on the loki:
http://www.sectorgame.com/ti-file-dump/VasudanAdmiral/FSU_Fixes/ScoobyDooHeightmap.zip (might need to copy+paste the link)
See what it looks like with this version of the normal map. :)
-
What effect/blend options did you use for the lines?
-
Here you go: http://img.photobucket.com/albums/v356/Shodan_AI/ratooth-bump.jpg (http://img.photobucket.com/albums/v356/Shodan_AI/ratooth-bump.jpg)
Also setting medium to 66%, large to 33% and verylarge at 0 also works too.
Why are the bolt holes elliptical in the bump map? That will result in elliptical holes. :nervous:
Also, jpg is not very good for transferring source files, the artefacts will look dumb when they get normalized... :blah:
I also made a couple versions of the height map and normal maps, and dumped it here (http://www.mediafire.com/?8j1owtycjd2), if you wanna check them out. I don't use Crazybump, though, those were made with varying settings on GIMP's normal map plugin.
-
Here you go: http://img.photobucket.com/albums/v356/Shodan_AI/ratooth-bump.jpg (http://img.photobucket.com/albums/v356/Shodan_AI/ratooth-bump.jpg)
Also setting medium to 66%, large to 33% and verylarge at 0 also works too.
Why are the bolt holes elliptical in the bump map? That will result in elliptical holes. :nervous:
Also, jpg is not very good for transferring source files, the artefacts will look dumb when they get normalized... :blah:
I also made a couple versions of the height map and normal maps, and dumped it here (http://www.mediafire.com/?8j1owtycjd2), if you wanna check them out. I don't use Crazybump, though, those were made with varying settings on GIMP's normal map plugin.
Probably because i'm using bevel and emboss layer style for them. I was using nvidias plugin filter for photoshop, but crazybump has more features, such as strength.
-
All I did was darken the white down to roughly mid-grey, selected the grey areas with the wand select so it left out the black plate lines, and then applied a round bevel to it all with the light set to come from directly above. This creates that strange fade blend thing you can see that I've found makes nice plates.
-
The loki map in the betas is the same as the one first page of this topic.
No, it's not. The rocky texture is much stronger in the VP version than it is in the earlier release.
The original release:
(http://img.photobucket.com/albums/v288/arceihn/loki1.jpg)
The Media VP release:
(http://img.photobucket.com/albums/v288/arceihn/loki2.jpg)
-
Well, it's the same one you decided to create a replacement for anyways VA.
-
I'm starting to worry about that rocky texture effect when I start normalling my cap ships. I'd probably create a bumpmap version of the base texture instead of desaturating the diffuse map and using that.
Sorry VA, don't really like it, suffers from the massive panel problem. I had found a sweet spot, but I forgot to write down the settings. :blah:
Think I found it: 99, 99, 66, 33, 0
You can definetely see it work when it's moving
(http://img.photobucket.com/albums/v356/Shodan_AI/ratoth2-normal.jpg)
after-thought.... you know that overly done Ulysses will fit perfectly with those few alien/crab ships i made ages ago,
-
The loki map in the betas is the same as the one first page of this topic.
No, it's not. The rocky texture is much stronger in the VP version than it is in the earlier release.
Wow....uh, yeah I just confirmed this looking at the actual files. It looks like the contrast was drastically increased or something. Thanks for pointing it out.
DaBrain, did you fiddle? :p
Scooby - what does that map I uploaded actually look like in-game? The pannels *should* be roughly the right shape, though possibly a bit tall. It's the right shape you're after though, because that's the tricky bit. Getting the correct overall intensity (height) after that is just a matter of the strength slider in crazybump.
-
I have to agree that I don't like the Loki's 'bumpy skin' too much. The other normal mapped details on it look good though.
And the model itself is of 1st class, of course :)
I liked the look alot. The tech description goes on about a "micro-roughened hull" - I know that it's unlikely to show up on a macro scale to that extent, but it looks good.
-
The loki map in the betas is the same as the one first page of this topic. The one I've just posted is a modified version of that same map that has a few minor fixes, and no texture roughness to it. :)
So, when the official VPs for 3.6.10 are released (presumably when the entire 3.6.10 release is made), some of these ships' maps will have changed slightly (or significantly) from those maps that were recently released in the beta VPs?