Author Topic: OutpostHD Graphics  (Read 56624 times)

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
OutpostHD Graphics
« on: July 19, 2017, 09:29:47 PM »
As requested, here is the thread for us to discuss potential OutpostHD graphics. Here is the quick proof of concept that I put in the other thread, reposted for convenience.



And at the possible desired scale of 128x64:




Some initial things that come to mind that we would need to sort out...
  1) Is there a desired style/theme in mind? Is this a recreation of original OP graphics, or a reimagined version...or something else.
  2) Is there a desired color scheme?
  3) Any animations?
  4) Size (which we briefly discussed) is pretty flexible, but will drive the detail size, amount, and quality.
  5) Are the graphics "1-sided" or will the user be able to rotate the map and see the back of the buildings?
« Last Edit: July 19, 2017, 09:43:50 PM by White Claw »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD Graphics
« Reply #1 on: July 20, 2017, 12:56:57 AM »
That is really cool looking. I'm really looking forward to the results of this.

Offline Goof

  • Jr. Member
  • **
  • Posts: 57
Re: OutpostHD Graphics
« Reply #2 on: July 20, 2017, 01:40:40 AM »
Actually it's PNG files with transparency.
Size depends on the structure size.
for example,
 - The communication tower is a sprite of 37x87 in a png file of 64x128
 - The agridome is a sprite of 71x43 in a png file of 128x64
 - The command center is a set of 16 sprites of 64x45 in a png file of 512x256 (animated as the antenna is rotating)

File size should be a power of two for each dimensions 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024)
For animations, it's just a series of sprites in the same file.
Some have moving parts (command center for example)
Some just blink some lights (surface lab)

See files attached.

Bye

Goof



Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #3 on: July 21, 2017, 12:24:44 AM »
I'm really looking forward to the results of this.

Actually, me too. I'm admittedly a bit excited about the potential here. :)


Actually it's PNG files with transparency.
Size depends on the structure size.

All extremely true, and I agree. However, since we are creating something new, I want to make sure that we're on the same page when discussing the structure of the data files. I imagine in the original OP, every byte of data storage space was fairly precious. That aspect is less of an issue now, so part of what I'm wondering is if we will start out with a standard format and size for all.

Also, thank you for the example pictures. They will be helpful as source material as we sort out the details.

Cheers

Offline Goof

  • Jr. Member
  • **
  • Posts: 57
Re: OutpostHD Graphics
« Reply #4 on: July 21, 2017, 01:45:03 AM »
All graphic resources for structures are in the "data\structures" of the binary release.
At least for the currently used structures.
You could also check the SVN to get the others too.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD Graphics
« Reply #5 on: July 21, 2017, 07:07:56 AM »
1) Is there a desired style/theme in mind? Is this a recreation of original OP graphics, or a reimagined version...or something else.

Ideally a reimagining. As much as I seriously doubt any IP DMCA notices will come through, I'd like to avoid any potential CnD's.

2) Is there a desired color scheme?
I'm slightly color blind and not great at designing visuals... I would say I leave this up to the developer. It would make sense to probably stick with a high tech somewhat neutral color scheme but that could lead to something very visually bland. So... I would say, I leave that up to the artist. :)

3) Any animations?
Animation would be awesome but I'm generally not expecting it because of the amount of work involved in it. The only things I'd really like to see for sure animated are the robots.

4) Size (which we briefly discussed) is pretty flexible, but will drive the detail size, amount, and quality.
I want to update the tilesets to use 128x64 tile sizes. As a note, this is just the 'tile size' and a a building will fit within the confines of a tile. Height is dependent on the requirements of the structure. A Comm Tower will naturally be taller than a Warehouse. So basically, whatever is appropriate. I'd suggest setting an orthograpic axonometric projection and just size buildings/structures to fit within the footprint of a tile. (I hope this makes some sort of sense).

5) Are the graphics "1-sided" or will the user be able to rotate the map and see the back of the buildings?
I'd considered view rotation but ultimately I don't think it will really add anything to the game. The tilemap isn't as visually dense as say, SimCity 2000 and structures generally won't be more than 1x1 tile in size (with maybe a few exceptions).


... I imagine in the original OP, every byte of data storage space was fairly precious.
They actually wasted more space than I've ever seen any game ever do. See attached for an example of how they wasted as many resources as possible.

To answer your question directly, I wouldn't worry too much about formats and sizes and whatnot. I've preferred PNG because it uses lossless compression though TGA with an alpha channel would work just as well.

Lastly, I would suggest rendering at high resolution and then we can scale them down for final inclusion in the game.



EDIT:

I attached a sample 'tile' to use for sizing. This is the tile size I want to ultimately shoot for. A building's footprint should fit within the confines of the tile (x/y plane) but can be as tall as it needs to be (z plane).



EDIT 2:

I attached a 3rd image that shows generally how a structure would be scaled to fit into a tile. This was a real quick photoshop hack job.

I did notice while cutting the building out that it's perspective is incorrect. The final render will need to be done using an orthographic projection. I don't know what modeling package you're using -- if it's Blender I have a .blend scene with the camera set up for exactly that -- it might help you figure out how to set up the camera projection.

Anyway, as I stated above, the final render does not need to fit 128x64. In fact I'd suggest rendering at least twice as large if not larger still. Having a higher resolution allows us to add fine details by hand if needed and then scale down for the final result.



EDIT 3:

A detail that may not be immediately obvious is that almost all structures are connected to eachother using tubes. If you look at the Command Center and Agridome that Goof posted, you'll see those along the long edges. You can basically look at it as each building is built on top of a 4-Way tube (last image in attachments). This allows them to fit with eachother kind of like lego pieces.

This post turned out way larger than I intended. Let me know if anything is unclear.
« Last Edit: July 21, 2017, 07:24:24 AM by leeor_net »

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD Graphics
« Reply #6 on: July 21, 2017, 07:43:13 AM »
Final note, I promise :D

An idea I'd played with in my mind was to use dynamic real-time lighting. This would require that the final rendered images do not have any lighting/shadowing applied and that a baked 'normal map' image be generated as well.

For example:



You can see here the 'diffuse' map which shows a zombie flat shaded and then the normal map above it. Combined with lighting, you get the resulting image on the right.

With a dynamic light you end up with the ability to shade a 2D sprite like this:



That's the general idea here with this. I don't know if you're familiar with any of this or unwilling -- in either case don't worry about it at all unless you're up to the task or willing to learn. This is a pipe dream anyway. :)
« Last Edit: July 21, 2017, 07:45:24 AM by leeor_net »

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #7 on: July 22, 2017, 01:07:49 AM »
Ideally a reimagining. As much as I seriously doubt any IP DMCA notices will come through, I'd like to avoid any potential CnD's.
Makes sense. Though if it's a reimagining, then there will most undoubtedly be some iterative design to get the style sorted out. I'm not super novel with my artistic abilities. :P

Animation would be awesome but I'm generally not expecting it because of the amount of work involved in it.

Idk yet how involved, but I don't imagine simple animations on par with what exists would be too difficult. I.e. lights that blink or comm dishes that spin. If/when we get to that point, we can sort out the file structure. (Or I can just try to make the images and someone else can pack them as desired.)

I want to update the tilesets to use 128x64 tile sizes. As a note, this is just the 'tile size' and a a building will fit within the confines of a tile. Height is dependent on the requirements of the structure.

I guess maybe my question in this area is still misleading. I'm trying to sort out if every building sprite would end up with a standard size, say, 128x128, which would accommodate fitting it within the terrain tile, but also be a standard height for all buildings. So that a comm tower sprite isn't some unique dimensions, which is wholly different from the dimensions of the command center sprite. I know the actual command center portions would be "shorter" than the comm tower, but would the whole graphic be a standard size.

I guess I ask because a standard size means I could set a standard camera setup at a standard distance from the model. That would make scale rather simple. I suppose it ultimately doesn't matter, since I can just render them all to some standard then post-process to crop all the wasted/unused space.


...how they wasted as many resources as possible.

Haha, I never really looked through the data files. I guess it's the opposite of what I thought, where the fact that they were free to use a CD meant they had endless space available.


I've preferred PNG...

PNG is the default format, so easy peasy.


Lastly, I would suggest rendering at high resolution and then we can scale them down for final inclusion in the game.

Also easy, though having a rough idea of size is good because that will set the detail requirements for the models.


Thanks for the examples. I think the camera for that was set up in perspective (I think I have that as the default), so sure, I can change to ortho.


A detail that may not be immediately obvious is that almost all structures are connected to eachother using tubes.

Yeah. In fact, I personally think getting the scale right on the tubes is the first priority. At least, that was my first priority when I was originally working on 3D OP buildings in that other thread. (That's when I realized I needed to up my modeling game.) The tubes, in my opinion, are the first thing that really set the scale. They have doors/hatches at the ends, which sets the overall scale of the tube (and by extension, pretty much everything else).


This post turned out way larger than I intended. Let me know if anything is unclear.

No worries, long posts are fine. Solid expectations and desires up front makes it more productive later. Plus there's usually delay posting back and forth, so having extra info is okay. I'm also happy to keep doing some of these quick hack jobs (like your photo-hack above) so that we can get the big picture sorted out without getting bogged down in details or unnecessary rabbit trails too early.
 

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #8 on: July 22, 2017, 01:19:37 AM »
You can see here the 'diffuse' map which shows a zombie flat shaded and then the normal map above it. Combined with lighting, you get the resulting image on the right.

This is a cornerstone of 3D modeling, so I'm familiar with the overall concept. I've heard of it applied to 2D sprites, but have not done it myself. Off hand I have some ideas on how to generate the normal maps (some more complex than others). We can certainly give it a try, though I also wonder how noticeable it will be given the likely dimensions of the sprites.

Do you already have a mechanism to implement this in your game engine? (Or concept on how it'll need to be modified.)

Tasks Thus Far:
- Establish a scale with tubes
- Initial investigation of animations
- Investigate methods for generating normal maps
- Generate Proof of concept for real-time shadows to determine shadowing detail
- Brainstorm theme and color scheme ideas
- Generate a list of required/desired/optional structures and vehicles (in priority order)
- Identify candidates for animation

Offline lordpalandus

  • Banned
  • Hero Member
  • *****
  • Posts: 825
Re: OutpostHD Graphics
« Reply #9 on: July 22, 2017, 02:16:10 AM »
Two thoughts on this topic:

1. Couldn't you animate just the dish, and apply transparency so that you didn't have to copy the entire structure in each sprite, for the sprite sheet... thus be able to animate multiple doodads on a structure independently?

2. Even if they had the ability to load tons of stuff on a CD back then, they'd still have the bottlenecks of the slow CPU, the very limited RAM, and the fact that CD-Drives back in those days didn't spin very fast... at best x4. So due to technical limitations storing stuff on a CD, may not have been beneficial back in the early 90s.
Currently working on Cataclysm of Chaos, Remade.
Link to OPU page = http://forum.outpost2.net/index.php/topic,6073.0.html

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD Graphics
« Reply #10 on: July 22, 2017, 03:41:48 AM »
Loved the zombie post. That was actually a really good illustration of normal maps and lighting.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD Graphics
« Reply #11 on: July 22, 2017, 06:15:00 AM »
Ideally a reimagining. As much as I seriously doubt any IP DMCA notices will come through, I'd like to avoid any potential CnD's.
Makes sense. Though if it's a reimagining, then there will most undoubtedly be some iterative design to get the style sorted out. I'm not super novel with my artistic abilities. :P

No worries. I would have expected an iterative process after all.


Animation would be awesome but I'm generally not expecting it because of the amount of work involved in it.

Idk yet how involved, but I don't imagine simple animations on par with what exists would be too difficult. I.e. lights that blink or comm dishes that spin. If/when we get to that point, we can sort out the file structure. (Or I can just try to make the images and someone else can pack them as desired.)

File structure is fairly straight forward. It's a series of animation frames packed into a single power of two texture. I can handle that, no problem at all.


I guess maybe my question in this area is still misleading. I'm trying to sort out if every building sprite would end up with a standard size, say, 128x128, which would accommodate fitting it within the terrain tile, but also be a standard height for all buildings. So that a comm tower sprite isn't some unique dimensions, which is wholly different from the dimensions of the command center sprite. I know the actual command center portions would be "shorter" than the comm tower, but would the whole graphic be a standard size.

I think you can use the command center as a sort of 'standard' building size. Most buildings will likely have their own unique size and structure so long as their footprint (the area of the base of the building) fits within the dimensions of a tile.


I guess I ask because a standard size means I could set a standard camera setup at a standard distance from the model. That would make scale rather simple. I suppose it ultimately doesn't matter, since I can just render them all to some standard then post-process to crop all the wasted/unused space.

You have the right idea, actually. My suggestion would be to set up a square plane in the scene to set as the 'tile size' and then ensure that buildings don't exceed the edges of that plane. Seeing as they're basically built on top of tubes, start with the tube structure (as you already mentioned) would make sense. Get that scale right and then use that as the base for the rest of the structures.


Lastly, I would suggest rendering at high resolution and then we can scale them down for final inclusion in the game.

Also easy, though having a rough idea of size is good because that will set the detail requirements for the models.

See above.


Thanks for the examples. I think the camera for that was set up in perspective (I think I have that as the default), so sure, I can change to ortho.

Perspective is the default... most renders are done that way anyway. :) We just dare to be different in isometric worlds.



... The tubes, in my opinion, are the first thing that really set the scale. They have doors/hatches at the ends, which sets the overall scale of the tube (and by extension, pretty much everything else).

I'm really glad I'm not the only one that noticed all that detail.  ;D


You can see here the 'diffuse' map which shows a zombie flat shaded and then the normal map above it. Combined with lighting, you get the resulting image on the right.

This is a cornerstone of 3D modeling, so I'm familiar with the overall concept. I've heard of it applied to 2D sprites, but have not done it myself. Off hand I have some ideas on how to generate the normal maps (some more complex than others).

Sweet! :D Sometimes when I talk to people about these sorts of techniques I get blank stares so I find it useful to ask ahead of time before I get into details.

We can certainly give it a try, though I also wonder how noticeable it will be given the likely dimensions of the sprites.

Very noticeable. My thinking is to use it mostly for environment lighting (e.g., sun) to provide a more dynamic looking scene that feels more alive than just the few little animations provided via the sprites. Additionally, lights emitted by buildings can be used to illuminate the scene as well... which means we should consider emissive maps as well (should be simple in modern render packages).

Do you already have a mechanism to implement this in your game engine? (Or concept on how it'll need to be modified.)

Yes and no. It's a fairly basic technique though. OutpostHD uses OpenGL as its core renderer... in order to get real-time lighting simply requires that I set up several frame buffers. A color buffer, a depth buffer and a basic lighting shader to compute light values across the scene and then finally spit out the results into the frame buffer. I've been playing a lot with OpenGL GLSL shaders lately and while NAS2D doesn't natively provide mechanisms for shaders I can still make direct calls to OpenGL to make it happen.

However... it's a low priority and won't run well (or at all) on less powerful hardware, so I'm thinking for now we do it without dynamic lighting and go for normal shading. Later when I'm ready to implement it we can rerender the images without shading, add the normal and emissive maps and provide dynamic lighting as an option.


Tasks Thus Far:
- Establish a scale with tubes
- Initial investigation of animations
- Investigate methods for generating normal maps
- Generate Proof of concept for real-time shadows to determine shadowing detail
- Brainstorm theme and color scheme ideas
- Generate a list of required/desired/optional structures and vehicles (in priority order)
- Identify candidates for animation

Looks good but I would for now stick with scale, animation, theme/color and list of prioritized structures/robots. We'll worry about the fancy stuff later.


Two thoughts on this topic:

1. Couldn't you animate just the dish, and apply transparency so that you didn't have to copy the entire structure in each sprite, for the sprite sheet... thus be able to animate multiple doodads on a structure independently?
Ideally, yes. But there are several concerns regarding this.

First and foremost, I never got around to frame composition in the sprite code. As of right now the sprite code looks up a list of frames and just plays them in sequence given an 'action name' and the speed in milliseconds to display a given frame.

This seems wasteful at first glance but then you have to take into consideration a few things. 1) Since this is a pure OpenGL implementation and not a standard 2D blitter, minimizing pixel over draw is much less of a concern. NAS2D uses stencil buffers under the hood to eliminate overdraw and this is all done on the GPU so few wasted cycles. 2) in terms of OpenGL, it's cheaper to just pull a part of a texture and apply it to a single polygon mesh (in this case two triangles composing a rectangle) than to pull a base frame and apply several smaller frames on top of it. I suppose that could be done via a shader in parallel on the GPU but that's kind of overkill. In this case it's just a matter of rendering a single quad with part of a texture applied to it. Quick and easy. 3) considering modern hardware capabilities, this would be an optimization that has little to no effect in the long run.

2. Even if they had the ability to load tons of stuff on a CD back then, they'd still have the bottlenecks of the slow CPU, the very limited RAM, and the fact that CD-Drives back in those days didn't spin very fast... at best x4. So due to technical limitations storing stuff on a CD, may not have been beneficial back in the early 90s.
At the time this game came out 2x CD-ROM's were the bleeding edge. I remember the day it came out and the day I installed it! :D

And you're right. The thing is, OP1 was probably the LEAST efficient game I've ever seen. For every single frame of animation it would load it directly from disk (it would install the BMP's to hard drive if you had it). Basically, as I was playing the game, for each frame the HDD would spin up. It was kind of annoying, actually, having the hard drive constantly chirping every second or so. And yeah, that was the frame rate. About one frame per second. And it would blit directly to the video memory (no back buffer) so you had animation that was updated on one side of the screen and you could actually watch the update phase as it would sweep from top to bottom. It was awful.  ::)

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #12 on: July 22, 2017, 01:16:01 PM »
Hmm, lots of things to get to in the last few posts, but I'll just drop this here for now while I mull over some of the other things.


Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD Graphics
« Reply #13 on: July 22, 2017, 02:45:58 PM »
That is pretty much perfect.

Side note -- these normals are intended for OpenGL, right? Not DirectX? For whatever reason both API's use different values.  ::)

Offline Goof

  • Jr. Member
  • **
  • Posts: 57
Re: OutpostHD Graphics
« Reply #14 on: July 22, 2017, 08:33:27 PM »
Side note -- these normals are intended for OpenGL, right? Not DirectX? For whatever reason both API's use different values.  ::)

As far as I remember Microsoft always had an issue with standards others that their owns.
PDF was leading the market, they create XPS.
Open Document was used by OpenOffice/LibreOffice/Anyone, they create "OpenXml"
OpenGL/DirectX

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #15 on: July 22, 2017, 10:50:10 PM »
For whatever reason both API's use different values.

I know, right?


Yeah, it should be for OpenGL. Took me a minute to check because (unrelated) Unity does things under the hood for OpenGL vs. DirectX so that programming either is constant. That made me forget which I was using. :P

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #16 on: July 22, 2017, 11:09:48 PM »
Looks good but I would for now stick with scale, animation, theme/color and list of prioritized structures/robots.

Sounds good. Now that I've had some practice, I can ideally improve upon the tubes I made six or so months ago. While I work on those, some questions on animations...

- Roughly how many frames for an animation? Are we talking in the five-ish range, or 20-ish range (or more)?
- Will each frame contain the entirety of the building (or vehicle, etc)? ... so that there are no animation overlays, just a single frame (as mentioned above)


Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #17 on: July 23, 2017, 11:23:28 PM »
Okay, here is my first draft at sorting out a scale. The little orange block is what I call "Figmo." Figmo is representing the rough size of a human. (First image is at 512x512, and second is 128x128.) Also, I added a ground texture for some sense of feel for being on a textured tile (that wouldn't be in a final render).





This scale is a terrain tile that is 80m x 80m. So the tunnel is 80m long, about 6m high, and about 10m wide. I don't know about going much larger here, say up to 100x100m. That might get a bit large, and I think the tubes would start to look out of proportion. Could make the sides a lot shorter, but not sure that I would go below 40x40m, and then the tubes might start to look a bit fat. I will try some of those other sizes this week and see what else looks good, but personally I like the proportions in what's shown above.

The one big drawback is that Figmo is pretty small in the 128x128, so not sure if animated people are desired. In which case I'll need to make the tube shorter, but I would also need to make sure the logical space in the buildings still makes sense.
« Last Edit: July 23, 2017, 11:36:21 PM by White Claw »

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD Graphics
« Reply #18 on: July 24, 2017, 07:14:31 AM »
Side note -- these normals are intended for OpenGL, right? Not DirectX? For whatever reason both API's use different values.  ::)

As far as I remember Microsoft always had an issue with standards others that their owns.
PDF was leading the market, they create XPS.
Open Document was used by OpenOffice/LibreOffice/Anyone, they create "OpenXml"
OpenGL/DirectX

Well, at least at the time DirectX was built it was about input and 2D graphics on Windows, something that you either did with shoddy drivers or with GDI which was slow as hell. So DirectX made sense as at the time graphics accelerators weren't common and OpenGL was still used for high performance workstations and CAD type programs. Plus OpenGL sucked to do anything with compared to DirectX in 3D until Khronos group FINALLY started improving the API and we ended up with GL 3.2. But I digress. :D

- Roughly how many frames for an animation? Are we talking in the five-ish range, or 20-ish range (or more)?

I think it's safe to say that this is objective. We could get as detailed as we want with hundreds of frames or make it super simple with only 4 or 5 frames. Both of these are at extremes. It comes down to what looks smooth with a target of 30FPS? In this case I'd think most animation would be in the range of 8 to 16 frames (current animation uses a default of 75 milliseconds between frames and that seems to be a pretty good animation speed.

- Will each frame contain the entirety of the building (or vehicle, etc)? ... so that there are no animation overlays, just a single frame (as mentioned above)

Right, no overlays. Just full frames. Sure, it's not super efficient but who cares? It's more efficient to pack everything into large texture atlases and reference that vs. switching between textures and most modern cards can support texture resolutions of 16Kx16K pixels... so let's roll with full frames and optmize later if necessary.



 :o I think I'm in love. This is entirely too perfect.

This scale is a terrain tile that is 80m x 80m. So the tunnel is 80m long, about 6m high, and about 10m wide. I don't know about going much larger here, say up to 100x100m. That might get a bit large, and I think the tubes would start to look out of proportion. Could make the sides a lot shorter, but not sure that I would go below 40x40m, and then the tubes might start to look a bit fat. I will try some of those other sizes this week and see what else looks good, but personally I like the proportions in what's shown above.

The one big drawback is that Figmo is pretty small in the 128x128, so not sure if animated people are desired. In which case I'll need to make the tube shorter, but I would also need to make sure the logical space in the buildings still makes sense.

I think you've got the scale and sizing absolutely perfect. The proportion looks and feels exactly like it did in the original game and is extremely realistic in terms of actual sizing. I sometimes forget that we can project real life measurements into scales so I never considered it but I think you've kit the nail right on the head.

As for humans, I wouldn't worry too much about seeing them. I mean granted, on the surface they'd be more visible because of the very bulk (and very bright colored) environment suits but I doubt they'd be rolling around the surface very much especially on extremely hostile planets.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #19 on: July 24, 2017, 06:41:33 PM »
I think you've got the scale and sizing absolutely perfect. The proportion looks and feels exactly like it did in the original game and is extremely realistic in terms of actual sizing.

Well that worked out well. I haven't measured precisely, but the original looks to be a bit "shorter" than the one I pictured above. The tunnels are about 5x longer than they are wide, whereas the ones I posted above are 8x longer than wide. I think that's about what I settled to before, since it made the other buildings feel a big better proportioned. If it's good, I'll stick with it.

Another question...the example iso tile you posted earlier (128x64)...Is that the proper size/proportions for your in-game terrain tiles? I want to make sure I set the camera angle properly for render.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD Graphics
« Reply #20 on: July 24, 2017, 07:45:29 PM »
... but the original looks to be a bit "shorter" than the one I pictured above. The tunnels are about 5x longer than they are wide, whereas the ones I posted above are 8x longer than wide. ... If it's good, I'll stick with it.

That's because they didn't get the perspective quite right. I was originally look to get a dimetric project (explained below) but I'm convinced that this is the perspective we should maintain.

Anyway, to answer directly, yes, it's good. It's very good.

Another question...the example iso tile you posted earlier (128x64)...Is that the proper size/proportions for your in-game terrain tiles? I want to make sure I set the camera angle properly for render.

It isn't right now but it was the original desired template (however I think this prespective will be perfect as I explain below).

The original artists for Outpost didn't get the perspective quite right. It's strictly isometric but most so-called 'isometric' games actually use what's called a 'dimetric' projection (think SimCity 2000, X-Com, Civilization II). That's what gets you that 2:1 pixel ratio along the edges -- e.g., for every two pixels you move left/right, you move one pixel up/down. My guess is this was easier for artists to draw by hand.

This isn't an issue so much anymore on modern machines especially with higher resolutions, higher bit depths, anti-aliased edges and fast hardware blending.



That stated, inspecting the tile render a little more closely, your projection appears to be true isometric.


As you can see from the outline, it doesn't -quite- match up to the 'perfect' shape. BUT, I'm not sure I really care. We're using anti-aliased edges on high resolution monitors so who cares?


The renders generate tiles that are 128x55 which fits just as well when assembled (which incidentally is exactly what you'd get if you scaled the current tiles by 1.196). As you can see from the image, there are no gaps and anti-aliased edges just make it that much more seamless. This works out well because it means that with this perspective we can scale the structures down to a width of 107x46 to get them to fit perfectly with the old tiles until we can get new 128x55 tiles.

So well done! The higher resolution and color depth gives a much need facelift to the visuals and they're a perfect fit for the current tilesets.



EDIT: When you get a chance, can you render this without the tile and with a transparent background? PNG or TGA with Alpha channel are both appropriate. Since this fits so perfectly with the current perspective I want to stick this into the game and see how it looks. If you can do a right and left tube as well it would be interesting to see how they look.
« Last Edit: July 24, 2017, 08:01:17 PM by leeor_net »

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #21 on: July 26, 2017, 07:48:31 PM »
So that it's in the thread...

Here's what we ended up with on the first draft of the tubes. I didn't really start out with the intention that these would be final products, but seems that we're happy enough at the moment.




I used this scale and started working on a command center. The first drafts were rather unremarkable.



One thing for sure, these are not intended to be final products, but more so molded clay as a discussion point. After bantering in IRC, I think that I may try an altogether new approach to the look of the command center. Please feel free to share ideas...I will try to put up more clay model concepts within a few days.

Offline dave_erald

  • Sr. Member
  • ****
  • Posts: 262
Re: OutpostHD Graphics
« Reply #22 on: July 26, 2017, 09:56:56 PM »
Wow. Well done sir. I'm late to the party I know

Tubes look great, and believable more to the point. The second model of what if I'm reading this correctly is a command center? If I were to place a wager I would say anything with that much exposed glass would look more at home as a greenhouse or a recreational center perhaps. The first one if there was something to mimic a robot command center of some sort (i.e. the center tower allowing a view of the surrounding field) I would think this to be it.

Keep at it. I'll try my hand at some useful suggestions for changes next rely if I'm not imposing
-David R.V.

-GMT400 fan
-OPU Influencer

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1015
Re: OutpostHD Graphics
« Reply #23 on: July 26, 2017, 11:46:21 PM »
I agree with Dave, these are looking great!

The tubes look well, exactly right to me. Nice job.

Some thoughts on the Command Center. Maybe try a hardened structure/bunker feel with antennas (maybe parabolic dish and a couple of helical antennas). Perhaps a thin row or two of smaller, reinforced windows.

Anyways, looking forward to seeing what you come up with!

-Brett

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: OutpostHD Graphics
« Reply #24 on: July 27, 2017, 11:08:51 PM »
Okay, okay.... I'm sorry...  I know I said I was working on a command center, but I had a little bit of inspiration and switched over to something else. Hopefully you can guess what it's supposed to be.




And on a game tile at the target resolution.