[BlackDove]

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.

[Taristin]

Just because everything can be replaced doesn't mean everything should be replaced.

[BlackDove]

Indeed. This should be replaced.

[Taristin]

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?

[StratComm]

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.

[knn]

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?

[StratComm]

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.

[taylor]

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.

[WMCoolmon]

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.

[Prophet]

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?

[knn]

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.

[BlackDove]

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.

[StratComm]

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.

[taylor]

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.

[FireCrack]

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"

[Taristin]

Curving the triangles != good. The jumpnode has to be triangulated IIRC. So most of the designs look like ass.

[Ulala]

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. 

[Starks]

If we update the node HUD, the rest of the IFF and HUD displays will be next.