Ah, now that you say that I feel really dumb lol

This is much better! You can't possibly go back to recording off the Mac mini now :P

Much appreciated that you made the effort to scale up the quality.

I liked this. I'm planning to get a new machine myself soon. The last one...marked "unstable build" had the shadows so dark I could not see the wall climber.
All said, this is really fun...I can't wait.

Gangrel wrote:

Cyclops wrote:
I liked this. I'm planning to get a new machine myself soon. The last one...marked "unstable build" had the shadows so dark I could not see the wall climber.
All said, this is really fun...I can't wait.

I *believe* that this is because it is an unstable build of the UnrealEngine for Linux... think "bleeding edge" version, where there WILL be bugs that crop up...

Surprisingly few. The shadows are more to not having configured it as of yet. Not a high priority at this time, since the main focus of the Linux build is for server work.

SavageFist wrote:

I know an Opteron is an AMD chip but are you guys also testing on any mainstream(ie consumer) AMD parts such as their HD 5000 and up series of video cards as well some Phenom or FX CPUs?
And the higher end machines made it look much more alive. Can't wait to see when animations are nearly finalized to a point where the art team can overlay the shinies so we can get a more fully realized look at our new home.

Every person has their own machines they work with. We have Athlons, Phenoms. i3 5 & 7's,, nVidia and AMD graphics cards, SSD and HDD's. Huge variety, which is the point.

Gangrel wrote:

Cyclops wrote:
I liked this. I'm planning to get a new machine myself soon. The last one...marked "unstable build" had the shadows so dark I could not see the wall climber.
All said, this is really fun...I can't wait.

I *believe* that this is because it is an unstable build of the UnrealEngine for Linux... think "bleeding edge" version, where there WILL be bugs that crop up...

More like "bloody edge". Perhaps not quite "Bloody Card", at least... but yeah, it was mentioned in the update that there are some known issues with the shaders on Linux. Frankly, that it was anywhere near that smooth, or that robust, says that Epic has done a stellar job of working on the Linux port. The technical details would bore most folks to tears, but the early revisions of stuff on a new platform tend to look worse than the Mac Mini here, when running on top-end machines.

So whatever else it does, the video serves as a *very* nice confidence builder for those of us who contributed in part for the Linux port that it isn't going to get lost in the shuffle the way UE3's port did. And yes, I have the original "release tin" of the Linux port back when they tried that on retail shelves. :)

Seahawk25 wrote:

I would just like to say that I love the design of buildings within the game, they look like they were taken straight out the comic books.

I love how the buildings look as well and the animations aren't looking to bad either for a early build. Looking pretty good so far

DeathSheepFromHell wrote:

Gangrel wrote:
Cyclops wrote:
I liked this. I'm planning to get a new machine myself soon. The last one...marked "unstable build" had the shadows so dark I could not see the wall climber.
All said, this is really fun...I can't wait.

I *believe* that this is because it is an unstable build of the UnrealEngine for Linux... think "bleeding edge" version, where there WILL be bugs that crop up...

More like "bloody edge". Perhaps not quite "Bloody Card", at least... but yeah, it was mentioned in the update that there are some known issues with the shaders on Linux. Frankly, that it was anywhere near that smooth, or that robust, says that Epic has done a stellar job of working on the Linux port. The technical details would bore most folks to tears, but the early revisions of stuff on a new platform tend to look worse than the Mac Mini here, when running on top-end machines.
So whatever else it does, the video serves as a *very* nice confidence builder for those of us who contributed in part for the Linux port that it isn't going to get lost in the shuffle the way UE3's port did. And yes, I have the original "release tin" of the Linux port back when they tried that on retail shelves. :)

Me too!

DeathSheepFromHell wrote:

It is also clear that even the last sample starts to hitch when it has a sightline to a huge chunk of world terrain, but that is basically throwing a *ridiculous* amount of load at the system, without doing anything but the most basic (built-in) adjustment for distance, and... yeah, frankly, I'm not too terribly worried about stuff being able to handle the map, as long as they don't try to actually treat it as a single giant map when doing it "for reals" (that would have much more severe problems for other reasons, anyway).

Tangential question to the point raised ...

For the City Maps ... are they going to include anything akin to "curvature of the Earth" in their underpinnings?

Most game maps out there are just flat plane constructions, because that's easy to do, and because when you can't fly it isn't something to observe. But City of Titans is going to have Flight, and camera viewpoints are going to be able to reach some appreciable altitudes (even if there isn't all that much "up there" to get at). Heck, just being able to go up to 2000 ft AGL will do appreciable things for how far away you ought to be able to see things due to curvature of the Earth.

Mainly this is a request to not set all of the elevations such that everything begins with an assumption of flatness. If you haven't built up your city yet, this ought to be a relatively simple thing to incorporate into the structure of the world environment. Gets a lot harder to incorporate AFTER you've placed all your buildings though.

Seriously? Planetary Curvature? Really guys? Wow. Even IF the devs were going to go THAT deep into sim territory, there is no way you would notice it with the size of the maps ANYWAY - so the point is completely and utterly moot.

Edit: or wait - are you talking about distance to the horizon and not the curvature of the horizon? Even still - the effect would be relatively tiny given the distances involved. The payoff would be irrelevant (especially if there will be "fog of war").

Now if we were on the body the size of Pluto - this might be worth considering - but as it is it's not worth the effort.

Not so hard that I can't calculate the difference. ^_^

Let's take as our worst case scenario a player with a bespoke gaming rig that can render the whole sixty-four square kilometers well enough to spot another PC at the opposite corner, call it 10,000 meters along the great circle. Yes, I'm rounding down to make the math easier ^_^

Now, the metre as originally defined was one ten-millionth of the distance from the north pole to the equator, or one forty-millionth of a great circle. We'll ignore the difference between that distance through Paris and that distance through Titan City. If we put both observer and observed at about 6,366,400 meters from the center of the game world, simple trig* gives us a straight line distance of 10,000.318 meters (again, rounded, this time to the nearest millimeter). We can also find the vertical distance** between that straight line and the great circle, 1.964 meters.

So, over most of the map, the difference between curved and flat is only two meters. And if we just tilted adjacent sections when they get added, by about 4.32 minutes of arc, we won't ever see more than that.

*sin(360/8000)*6366400

**6366400-((sin(360/8000)*6366400)/tan(360/8000))

[I]edited tilt of adjacent sections error[/i]

Hmmmm.... its like asking someone, Would you rather have Quantity over Quality?
I rather prefer Quality. Less is More! ;)

Redlynne wrote:

DeathSheepFromHell wrote:
It is also clear that even the last sample starts to hitch when it has a sightline to a huge chunk of world terrain, but that is basically throwing a *ridiculous* amount of load at the system, without doing anything but the most basic (built-in) adjustment for distance, and... yeah, frankly, I'm not too terribly worried about stuff being able to handle the map, as long as they don't try to actually treat it as a single giant map when doing it "for reals" (that would have much more severe problems for other reasons, anyway).
Tangential question to the point raised ...
For the City Maps ... are they going to include anything akin to "curvature of the Earth" in their underpinnings?
Most game maps out there are just flat plane constructions, because that's easy to do, and because when you can't fly it isn't something to observe. But City of Titans is going to have Flight, and camera viewpoints are going to be able to reach some appreciable altitudes (even if there isn't all that much "up there" to get at). Heck, just being able to go up to 2000 ft AGL will do appreciable things for how far away you ought to be able to see things due to curvature of the Earth.
Mainly this is a request to not set all of the elevations such that everything begins with an assumption of flatness. If you haven't built up your city yet, this ought to be a relatively simple thing to incorporate into the structure of the world environment. Gets a lot harder to incorporate AFTER you've placed all your buildings though.

While I cannot speak to what may or may not eventually happen, I can certainly speak to where and how the data originated, and what state it was in when I was last involved with it.

WARNING: The following is almost certainly not of interest to anyone who isn't a "map geek". For everyone else, just contemplate the amount said here, and my typical penchant for perfectionism, and draw your own conclusions. :)

-----

The simplest answer is "it has a complete and formally defined CRS" (Coordinate Reference System). Said reference system uses the WGS-84 base, with its origin at a specific point that is relevant to the data in question (and is reasonably "close-ish" to the center of the city map), plus sufficient false easting and northing (~200k each, IIRC) to accomodate future expansion without needing to get into negative coordinates.

Horizontal scaling is set to 1m because that's what the various data sources had and because it makes it trivial to get correct scaling within the engine (just set the X/Y scaling factor to 100). Vertical scaling is set to 1cm so that it can represent a sufficiently accurate level of detail that it should exceed the accuracy of the source data in more or less all cases, and retain detail sufficient to preserve any "hand-sculpted' work, even prior to smoothing in the engine.

However, I will also note that there were some unresolved technical concerns about the vertical resolution and possible impacts on playable space, so I definitely would *not* assume that one will necessarily stay as it was -- I would expect the question to be decided by play testing and some experimentation.

Due to the nature of the engine, the data has to be stored as a simple 2D grid; however, these were generated as equirectangular projections of the source data, which came in a variety of projections and resolutions; as such, there are definitely some portions of the map where values are not-necessarily-trivial interpolation from the input data due to the mathematics of reprojection.

While I was working with it, the "midpoint" of the Unreal data (16-bit unsigned integer, so 32767) was mapped to the mean sea level (MSL) recorded for the origin data sets. This, like the vertical resolution, may be subject to change (in fact, if it is, it will probably be for the exact same reasons).

While it is not my place to discuss where the original data came from (and it may well change, if other data sources are hybridized in), the information I did my work from covered both high-resolution LIDAR scans (for onshore elevations) and multiple resolutions of sonar-derived bathymetry for the offshore depths.

Due to a combination of gaps in the data and the fact that LIDAR data treats "water surface" as if it were a land elevation, a non-trivial amount of masking and layer selection was done, based on both data evaluation and visual referencing against high-resolution digital orthography.

-----

So is it curved? Sort of yes, sort of no. The original data is curved, and the results are stored in a projection which could be reversed into curve-relative data, but since the engine needs a flat data set the actual *terrain* data is stored in that format. But all of the relevant information to convert between the two was stored, and the handling of it was specifically done with an awareness of distortion concerns, and all of the practical measures I am aware of were taken to minimize the effects of distortion.

That answer the question sufficiently? :)

It answers the question well enough to confirm that curvature of the Earth is an option, even if it doesn't get (or need to be, at first) used.

DeathSheepFromHell wrote:

...and multiple resolutions of sonar-derived bathymetry for the offshore depths...

That certainly sounds better than the waist-deep-at-most oceans that we found in a (relatively) recent MMORPG set a (really) long time ago in a galaxy far away. It always annoyed me that a game from 2004* could do proper oceans but one released seven years later couldn't...

But it sounds great for crashed space ships, evil villains' yachts, fish men who won't return their library books...

*[I]I was thinking about WoW. Did CoX have proper oceans?[/I]

I would LOVE well done and well utilized bodies of water in CoT too. Always really wished we had them in CoH

Is this something that has to be present in the game from the get-go, or is it feasible for it to be on the "eventually" list?

It IS something I would love to have in the game. It's NOT something I'd want to delay launch specifically for--unless it's an all-or-nothing "there from the start or it's to difficult to work in later" type of thing.

I think temp powers are the way to go for a swimming mechanic. Unless it got to be that there was such a vast majority of under water material that warranted a fully permanent travel power or something of the like

As to whether it has to be there at launch or can be added later: the conceptual support has to be there at launch, but that is almost trivial to ensure; all you have to do is *not* make glaringly unwarranted assumptions such as "the lowest possible elevation that can be represented is sea level". Since there are a wide variety of reasons that things might dip below that, the first pass used "the middle elevation" as sea level. By way of comparison, sea level on Minecraft is, unless I mis-remember, at either 60 or 64 "units" high, out of an original 128 total vertical capacity. Or to put it another way: "half way up", exactly the same as the first pass at map terrain.

One of the known-and-not-yet-really-addressed concerns is that it might end up needing to shift or rescale in order to have enough above-ground vertical. However, this was left unaddressed primarily because A) it really is something that warrants playtesting to decide if it is even an issue, and B) using the proper tools makes it simple to adjust how things are "translated", relative to Mean Sea Level (MSL). This is one of those cases where the tools for CoT (or at least the ones I did) were built specifically to take advantage of the fact that there are existing suites with literally *decades* of development done on them, which specialize in exactly this kind of task. I can't speak to anything that may have happened since my stint, but I absolutely planned for my plans to plan against me. Former mastermind, and all. :)

-----

Redlynne makes an excellent point regarding "if you don't build it *interestingly*, they won't bother to come". All I can say here is that my focus was strictly on making sure that the tools and data didn't specifically "lock out" the possibility. I know that the lore folks were aware of the potential for "offshore" content, in a general sense, but any details I might happen to know aren't mine to give out -- and frankly, there simply couldn't be that many of them in the first place, as I doubt that Lore would focus heavily on it unless and until they had a green light saying "assume we can make this work in a technical sense".

------

Honestly, I have to mostly disagree regarding "swimming" as a separate travel power. Unless it is truly as much of the game as "onshore" is, which would be difficult to do simply given the relative surface areas involved, it isn't really viable to "charge" the same cost. And speaking from experience as a user (on RIFT most recently, but also elsewhere), if you have a breath mechanic, the only thing it will cause players to do is desperately hound you for some form of permanent device or other goodie that lets you ignore the *censored* thing. It is hard enough to get folks out to explore an underwater area in the first place, in most cases; doing *anything* to discourage them is usually a guarantee of failure. It only worked on RIFT because it tied into a timed challenge for a perk / badge, but I think all of maybe 5% of the players who ever bothered to go underwater (which was already a tiny fraction) ever bothered. I did it because I'm an obsessive completionist, and had finished all the land-based exploration badges. And then never went back until they offered a permanent device.

Champions frankly handled this fairly cleanly: in a mechanical sense, you can swim anywhere, and they simply leave it up to the player's imagination to explain how their character is doing it. The main exception to "you explain it" is that the very first mission in the *zone* that is entirely underwater and which they expected lots of folks to go to amounts to "here's a MacGuffin of Water Breathing; go fetch replacement materials so the next poor sod can have one too". Clean, elegant, gives you a milk run to get used to the fact that water environments tend to be 3d in significant ways that even most aerial environments aren't (did you remember to look up before rising, or are you heading straight up into a mob?), and gives all the excuse one could reasonably need for suspension of disbelief (I mean, c'mon, we're talking about supers in the first place, here).

-----

As for "swimming is just flying", well, just, but by the same token "flying is just jumping" (and then failing to hit the ground). CO really mostly got this one, too, although for a while they had a serious partial failure. If your travel power causes you to go from point A to point B by crossing the intervening space, just turn it into a swim mechanic at the engine level. If you don't cross the intervening space, then don't do it underwater either. Although it does remove the question of falling after your teleport. :)

DeathSheepFromHell wrote:

If you don't cross the intervening space, then don't do it underwater either. Although it does remove the question of falling after your teleport. :)

In my humblest opinion, after a Teleport, the player shouldn't fall for a few seconds, 2 to 3. If you TP onto a platform, the game should realize it doesnt need to do a TP Hover. And yes, i'm saying a TP Hover for 2 to 3 seconds Should have been there in CoH/V all along. >:(

I'm not surprised the sonar data was a lot messier than LIDAR. Light goes in pretty much straight lines through a constant-consistency medium, which makes the angle-and-time-to-spatial-coordinates conversion rather straightforward; the biggest errors are usually in platform position data.

Sound in water, on the other hand, has to deal with much slower wave speeds (1500 m/s in sea water), leading to much less angular resolution (beam width) for a given aperture because the wavelengths are so much larger. And that's only the start of it; the speed of sound changes significantly with temperature, and temperatures are all over the map, so sound waves generally don't travel in straight lines. Standard sonars usually discard vertical-angle information, and either don't ray-trace or assume the sound came from the angle where the system responds the strongest, which is rarely the case. Which is plenty good if you're trying to map out shipping channels or find the Titanic, but lousy if you're trying to make a meter-horizontal-centimeter-vertical accurate map of the seafloor. And this is ignoring the multipath interference, where the sound waves bounce off the not-flat surface and/or the seafloor and present false returns, a bigger problem when that multipath gives you a stronger signal because it involved a reflection off a bright target...

Empyrean wrote:

DeathSheepFromHell wrote:
Champions frankly handled this fairly cleanly: in a mechanical sense, you can swim anywhere, and they simply leave it up to the player's imagination to explain how their character is doing it.

Agreed. In a game where freedom, customization, and your own story are emphasized, just let people swim.
It's up to the individual player whether they just ignore the whole "how" issue (lazy, but their dime), make it part of their hero's bio/powers that they have that ability, or address it with a costume piece/change.
Easy peasy AND free and individual customization. Complex solutions are clever and interesting, simple solutions are elegant and powerful.
This would by far be the best way IMHO.

I don't recall how far back I had multiple costume slots for even new characters in CO, but once I did have a second slot, unless the first slot had it covered already (powered armor, for example) or the character concept didn't require it (like [url=http://cityoftitans.com/comment/49480#comment-49480][font=lucida bright]AIko[/font][/url] who is a robot), I'd make an underwater version of the costume, usually with scuba mask and fins and often an air tank, and used it whenever the story brought the character underwater.

Lin Chiao Feng wrote:

I'm not surprised the sonar data was a lot messier than LIDAR. Light goes in pretty much straight lines through a constant-consistency medium, which makes the angle-and-time-to-spatial-coordinates conversion rather straightforward; the biggest errors are usually in platform position data.
Sound in water, on the other hand, has to deal with much slower wave speeds (1500 m/s in sea water), leading to much less angular resolution (beam width) for a given aperture because the wavelengths are so much larger. And that's only the start of it; the speed of sound changes significantly with temperature, and temperatures are all over the map, so sound waves generally don't travel in straight lines. Standard sonars usually discard vertical-angle information, and either don't ray-trace or assume the sound came from the angle where the system responds the strongest, which is rarely the case. Which is plenty good if you're trying to map out shipping channels or find the Titanic, but lousy if you're trying to make a meter-horizontal-centimeter-vertical accurate map of the seafloor. And this is ignoring the multipath interference, where the sound waves bounce off the not-flat surface and/or the seafloor and present false returns, a bigger problem when that multipath gives you a stronger signal because it involved a reflection off a bright target...

"Ayup"

The "generic" sonar data (broad-scan and covers basically everything) is at 30m horizontal resolution, and I don't recall the details of the vertical resolution except "if you have to ask, you're expecting way too much". Which is pretty much your utterly generic "standard sample for being able to see mountains and cities but not necessarily buildings". By comparison, SRTM data for more or less the entire earth provides this for anywhere onshore, and is nearing... 20 years old, now?

There *is* a subset of much more accurate data, sampled using multi-beam sonar. Which, done right, allows for all sorts of neat tricks in terms of detecting and reducing the influence of many of the factored named, without necessarily even having to know the exact nature. But even that is definitely and distinctly "not especially perfect". Most of the significant gaps are places where, looking at the overlays and patterns (and sometimes the overflight photos), there was something that prevented getting reasonable readings.

Getting those things blended well and turned into a sufficiently complete topographical surface to be usable is definitely a larger task for the underwater part. The good news, on the other hand, is that the Unreal editor just so happens to have tools in it specifically for "sculpting" terrain using a wide variety of approaches, and when I went to patch over a few holes in one of the sample maps to see what it would take, it wasn't particularly onerous.

Which doesn't mean *I* did a great job with them (I honestly can't tell beyond 'seems reasonable to me'), but I would expect someone with any degree of actual artistic talent to not have too much trouble. :)

Also, should there turn out to be any truly huge gaps, it would be relatively straightforward to adapt the current tool chain to take additional inputs, and then feed in data generated from any of a variety of world-building tools or fractal terrain generators.

After reaching Level 30 and seeing the Crey agents for the first time, I did something similar. I made a Crey costume for Redlynne as an alternate slot, and just never got rid of it.

[img]http://i.imgur.com/MuyZguW.jpg[/img]

So naturally on any Mission that took us up against Crey, I'd switch to my "undercover" Crey costume ... or as I preferred to think of it, as my "Evil Executive Secretary" costume. Made a nice change from my more typical Tights, Stripes & Sneakers look.