Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: -moose- on February 13, 2006, 12:38:45 pm
-
are supposed to be green wireframe, correct?
i wasnt sure if i was missing out on something, because everything else looks spectactular
-
Yups, that's what they're supposed to be.
Jump nodes don't have a physical appearance and the green wireframe is a HUD artifact so you can actually tell where one is.
-
Maybe we should...update the green wireframe into something cooler.
And by we, I mean people with skills.
-
How can you make something cooler out of a HUD artifact? :rolleyes:
It's just a computer generated nav! It's supposed to look dull and simple! :hopping:
Ofcourse it could be a cool colourful animated flashing sign: "jump here"
But every craft that gets in range of it would suffer critical systems failure when their CPU and nav systems try to display the "HUD artifact". Its not a laughing matter when the graphics processor attached to the navigation system overheats and causes a fire alarm on a space ship!
:p
-
.......right.
It wouldn't hurt for it to look snazzier.
-
Actually, IIRC it would... because jump nodes have a different kind of renderring pass which is more intensive for some reason.
Not sure if it's been changed but I doubt it.
-
I think the wireframe rendering has been optimized lately, but in reality you don't want it getting any more complicated than it already is. So long as it's a collection of green lines, the only way to make it recognizable at all is to keep the number of lines to a minimum. If they get too numerous then they run together an you can't make out anything more than the basic shape.
-
Jump node models use the same rendering function as any other model, so you could conceivably make a model that just uses normal textured polygons and such. I'm not sure why you'd want to though.
-
How about making some of the portions between the green lines, covered in a transluscent green texture?
-
Why does it need to be changed at all?
-
I think adding just a few more poly shapes to the wires would be nice. Just enough so that it doesn't look like a potato when you're viewing it from some angles. Nothing too fancy.
-
I guess that what you're wanting changed is that the side pieces are three-way instead of four way, so from certain angles one side looks more "full" than the other. I'll be honest, I prefered the FS1 node to the FS2 one for that. But the FS2 one looks cooler. I'm of the opinion that the node needs to stay as close as possible to the FS2 retail node if a replacement is going to be in there at all, so I would vote against a "revamped" or "HTLized" jump node. It's one of those things that should stay simple.
-
I think adding just a few more poly shapes to the wires would be nice. Just enough so that it doesn't look like a potato when you're viewing it from some angles. Nothing too fancy.
Its a sphere! Its gona look lika a potato no matter wich direction you look it from :lol:
I agree with StratComm. It has to be kept clean and simple.
-
Definitely another vote against changing it. The wireframe look really fits what the node display is supposed to be: a simple graphical indicator generated by your HUD. If you've ever seen the HUD of an actual fighter, the graphical overlay there is pretty much the same style. The node display does exactly what it needs to do without any frills attached; plus, and above all else, changing it at this point would be incredibly strange, given how we're all completely used to the original one. Spending polies to make ship models look better is one thing; spending them to make a wireframe HUD representation of an invisible singularity in space look better just seems like overkill. :p
-
There should already be a high-poly version in the mediaVPs anyway.
-
I think adding just a few more poly shapes to the wires would be nice. Just enough so that it doesn't look like a potato when you're viewing it from some angles. Nothing too fancy.
Its a sphere! Its gona look lika a potato no matter wich direction you look it from :lol:
I agree with StratComm. It has to be kept clean and simple.
Sphere =/= potato. :hopping:
Anyway, the node is 44 polygons with 2 stars with 3 points at the poles and 3 stars with 4 points around the equator. The mv_models version is 204 polys but the same layout. I'm just saying that making the layout a little more spherical wouldn't hurt. I would just make an icosahedron and stick the 3 point star wire thingy (but smaller) at each of the 12 verticies. That's 252 polys with the hi-res node wireframe 3 point star.
-
Not wanting to really get in on this conversation I'll just add this... jumpnodes still go through the old non-HTL line drawing code. The wireframe code was redone to work properly in HTL mode but it only works for texture mapped polys, which the original jumpnode is not. The original jumpnode isn't rendered as wireframe in the more basic sense but is instead basically just a bunch of points connected by lines. The original jumpnode cannot be drawn properly using HTL code because of this. The more complex the jumpnode model is the slower it is to draw because it's always non-HTL lines and is always rendered one line at the time. Making a more detailed jumpnode model which can actually draw fast would require code changes that are incompatible with the retail jumpnode model. I know, I tried it already. It was just far too messy to try and handle both the retail model and more fancy ones properly.
Personally I'm happy just sticking with the retail jumpnode. The mv_models version is at least 3 times slower to draw (depends partly on video card/driver, could be much slower) and the extra polys just aren't worth it to me. Perhaps in the future the code will be reworked to allow for multiple jumpnode types that can work with both the retail version and hi-poly/textured models without sacrificing speed in either case.
-
^^ see! I thought so!
-
"^^"?
"^^"?
The penalty is death.
....at any rate, the green wireframe looks a good eight years old. A way to change it should really be found.
-
"^^" as in up arrows. Grow up. :doubt:
And they don't look old at all. They look standard. They look correct.
-
They look old, because they are old. Wether you think they're fine or not is beside the point. It's old, and there are better ways for it to look by now.
And as far as "^^" goes, whatever it means, it's still "^^" and therefore death is the appropriate penalty.
-
Just because everything can be replaced doesn't mean everything should be replaced.
-
Indeed. This should be replaced.
-
No. It shouldn't. Did you miss the whole part on how each line is drawn seperately? How it uses non-HTL code for node renderring?
-
Not wanting to really get in on this conversation I'll just add this... jumpnodes still go through the old non-HTL line drawing code. The wireframe code was redone to work properly in HTL mode but it only works for texture mapped polys, which the original jumpnode is not. The original jumpnode isn't rendered as wireframe in the more basic sense but is instead basically just a bunch of points connected by lines. The original jumpnode cannot be drawn properly using HTL code because of this. The more complex the jumpnode model is the slower it is to draw because it's always non-HTL lines and is always rendered one line at the time. Making a more detailed jumpnode model which can actually draw fast would require code changes that are incompatible with the retail jumpnode model. I know, I tried it already. It was just far too messy to try and handle both the retail model and more fancy ones properly.
Personally I'm happy just sticking with the retail jumpnode. The mv_models version is at least 3 times slower to draw (depends partly on video card/driver, could be much slower) and the extra polys just aren't worth it to me. Perhaps in the future the code will be reworked to allow for multiple jumpnode types that can work with both the retail version and hi-poly/textured models without sacrificing speed in either case.
The whole point of putting that model into MV_core was to allow the jumpnodes to be drawable with HTL rendering code in the first place. In fact, that's the only reason I even made it. If it's not achieving that, then it should be removed. Why it's in mv_models now is beyond me, as it was never supposed to go there.
-
Couldn't you make a command line option like 3dwarp that uses the model (which should be in mv_core) and the HTL rendering code?
-
If that were the case, the old node would have to be permanently added as a hard-coded data structure within the game engine itself. I'm thinking the chances of that flying are next-to-nil.
-
Couldn't you make a command line option like 3dwarp that uses the model (which should be in mv_core) and the HTL rendering code?
No. The point is that using the HTL method makes it impossible to use the original model. You can use or not use -3dwarp and it works fine regardless. Using the HTL rendering method for the original jumpnode model would either crash (very likely) or just not render anything at all. It's a feature that officially breaks retail data compatibility and that's not acceptable. This isn't something that can be covered over by a simple hack (already tried ;)) as it needs a whole new capability to make it work properly (see below).
The whole point of putting that model into MV_core was to allow the jumpnodes to be drawable with HTL rendering code in the first place. In fact, that's the only reason I even made it. If it's not achieving that, then it should be removed. Why it's in mv_models now is beyond me, as it was never supposed to go there.
And I've asked for it to be removed for the past 3 MediaVP releases in fact. It's still there though, just slowing things down.
If that were the case, the old node would have to be permanently added as a hard-coded data structure within the game engine itself. I'm thinking the chances of that flying are next-to-nil.
The new node POF would have to permanently added to the code in order for the rendering path to go HTL actually. I already coded everything up when I was working on the new HTL wireframe view but that basically makes it impossible to use the original model, or to even supply your own for that matter. Trying to figure out if it should get rendered with the HTL or non-HTL path was buggy as hell (to say the least) so I never added that code and decided to just leave it with the non-HTL path.
What is likely needed is a jumpnode tbl (probably just added to one of the hud tables, or a ship specific thing) so that a model and rendering type can be specified. This would allow easy use of many different jumpnode model types. It's unlikely that every race would have a jumpnode indicated the same on the HUD so this would allow per-ship/species setting of how to indicate a jumpnode location in space. It's possible to do without a ton of work, but time is short and this is an extremely minor feature as far as I'm concerned.
-
Actually you can already specify jumpnode model...but it will still use the same rendering method as I didn't code in a way to swap flags.
-
They look old, because they are old. Wether you think they're fine or not is beside the point. It's old, and there are better ways for it to look by now.
Really? Like what? What is a better way to indicate a HUD artifact marking an invisible point in space, than a wireframe of a sphere? A wireframe that looks like a phallus?
-
What I meant was to use the original code on the original model if the parameter is not specified, and use your new HTL wireframe code with the new model (if present, otherwise revert to original code and model) if specified. Just give a different name to the HTL model, and use the filenames to choose the rendering path. As for the table specified jumpnode model, use the new code for them. Since this is not a retail feature, it won't be breaking compatibility if HTL-compatible models are required.
-
They look old, because they are old. Wether you think they're fine or not is beside the point. It's old, and there are better ways for it to look by now.
Really? Like what? What is a better way to indicate a HUD artifact marking an invisible point in space, than a wireframe of a sphere? A wireframe that looks like a phallus?
A wireframe that looks cooler.
-
And what, prey tell, would look cooler? Again, "this sucks" isn't helpful.
Not that I'd let a substantially different node get into the Media VPs anyway.
-
Yeah, about the only way this is going to get some coder support any time soon is if someone actually makes a much better jumpnode model. And a full set of jumpnode models representing current outline, new wireframe, and also textured models (assuming it's useful) would be even better since something like that just gets the creative-coding juices flowing.
If a "new and improved" jumpnode model is just the same basic thing then there is no real reason to make the required code changes.
-
Well, i suppose you could make it so that the edges of the triangles were curved to fit the contour of a sphere better, but that's kinda starting to border on "realy not worth it"
-
Curving the triangles != good. The jumpnode has to be triangulated IIRC. So most of the designs look like ass.
-
I think the juimpnodes look fine.. they're all they need to be really. I do, however, also see potential for some cool ideas that could come from some modification. But I don't have any cool ideas, myself. ;)
-
If we update the node HUD, the rest of the IFF and HUD displays will be next.