Dev Asks: Killing voxels

[tsunamayo]

Hello again! Sorry for the long post, I wanted your feedback on the following big tech move I would very much like to take. Starship Evo started its life as a voxel-based building game like many other. Over time I have been able to switch to a new stretching tech, keeping voxel logic in a few places. With the latest physics refactor I am now in a position of being able to completely move away from voxels and embrace the true potential of the stretch tech. I am very much want to do this move for many reasons, but it might be unpopular.

Now those are two very opposite philosophies: Voxels:

• Simple and elegant, nice algorithms.
• Grid locked, ie you cant place stuff where you want
• block have to conform to a cubic bounds of a fixed size
• Big memory requirement

Stretch tech

• can have any shape or any size
• can position everywhere
• small memory footprint
• some stuff are impossible to do

The gains: For now I had an hydrid tech, which means some of the pros of both but also some of the cons. Getting rid of the last voxel bits would mean a massive boost in code simplicity, memory requirement vastly reduced, faster shader (so higher FPS). This also means I could more easily unify bricks and hull block gameplay wise, it would seems more logical from a player perspective. The big thing is that with a true 100% stretch tech there is no difference in term of perf and memory impact between a 50m long and a 5km long build with the same number of bricks. => The very sexy bit for you the player is that switch would mean the addition of big block (4m) and mega blocks (16m) (maybe BFB - 64m, I want to keep that rule of 4 which makes a lot of sense.). Ultimately I could replace the rings by a bricks based entity, again simplifying my code and leveraging on the community ability to make me good looking, large and varied stations instead of spawning the same ring everywhere. Granted it would require some dev, especially to use with procedural terrain. But that would possible and again allow me to get rid of my "space habitat" code.

Now that would mean we loose the "voxel remnants":

• Voxel paint: this one should be okay as we have decals. I would give a 1m wide decal locking to the 1m grid so you guys can paint easily. Actually a lot of people are sick of voxel paint for large build.
• Smart Border on hull: (the adjacent aware border, not the stretch border that would stay) this one suck as I think it was looking great. I did some test and honestly it was not that much a big of deal. I will tone down the border, maybe remove/tone down the normal so that they are lot smoother. It would suck a bit at the beginning but we will forgot about it after a while. A great looking ship would still looks great...
• Voxel damage. I think that system was working well, except that it is a huge pain in the ass to work with. But that would mean brick and hull would be unified (they would be the same really, except for the size and their base property). One issue is that a large slab would be a lot harder to penetrate than a smaller slab, and some people might feel pushed toward building long and large (that was the reason I did a voxel base damage model). I could deal with that in several way so I am not too afraid about this.
• Cannot use the grid for future dev also, like pathfinding. I will find a way.

This gets me excited. I really cant wait to see what you guys could do at the scale of several km. I think it fits the philosophy of the game and my vision with the large solar system. I think we should do it. What is your feeling on that?

[Kaiser-Indrasil]

FIRST NEO-VOXEL GAME, LET'S GOOOOOOOOO

[ultrak2k]

Hello again! Sorry for the long post, I wanted your feedback on the following big tech move I would very much like to take. Starship Evo started its life as a voxel-based building game like many other. Over time I have been able to switch to a new stretching tech, keeping voxel logic in a few places. With the latest physics refactor I am now in a position of being able to completely move away from voxels and embrace the true potential of the stretch tech. I am very much want to do this move for many reasons, but it might be unpopular.

Now those are two very opposite philosophies: Voxels:

• Simple and elegant, nice algorithms.

• Grid locked, ie you cant place stuff where you want

• block have to conform to a cubic bounds of a fixed size

• Big memory requirement

Stretch tech

• can have any shape or any size

• can position everywhere

• small memory footprint

• some stuff are impossible to do

The gains: For now I had an hydrid tech, which means some of the pros of both but also some of the cons. Getting rid of the last voxel bits would mean a massive boost in code simplicity, memory requirement vastly reduced, faster shader (so higher FPS). This also means I could more easily unify bricks and hull block gameplay wise, it would seems more logical from a player perspective. The big thing is that with a true 100% stretch tech there is no difference in term of perf and memory impact between a 50m long and a 5km long build with the same number of bricks. => The very sexy bit for you the player is that switch would mean the addition of big block (4m) and mega blocks (16m) (maybe BFB - 64m, I want to keep that rule of 4 which makes a lot of sense.). Ultimately I could replace the rings by a bricks based entity, again simplifying my code and leveraging on the community ability to make me good looking, large and varied stations instead of spawning the same ring everywhere. Granted it would require some dev, especially to use with procedural terrain. But that would possible and again allow me to get rid of my "space habitat" code.

Now that would mean we loose the "voxel remnants":

• Voxel paint: this one should be okay as we have decals. I would give a 1m wide decal locking to the 1m grid so you guys can paint easily. Actually a lot of people are sick of voxel paint for large build.
• Smart Border on hull: (the adjacent aware border, not the stretch border that would stay) this one suck as I think it was looking great. I did some test and honestly it was not that much a big of deal. I will tone down the border, maybe remove/tone down the normal so that they are lot smoother. It would suck a bit at the beginning but we will forgot about it after a while. A great looking ship would still looks great...
• Voxel damage. I think that system was working well, except that it is a huge pain in the ass to work with. But that would mean brick and hull would be unified (they would be the same really, except for the size and their base property). One issue is that a large slab would be a lot harder to penetrate than a smaller slab, and some people might feel pushed toward building long and large (that was the reason I did a voxel base damage model). I could deal with that in several way so I am not too afraid about this.
• Cannot use the grid for future dev also, like pathfinding. I will find a way.

This gets me excited. I really cant wait to see what you guys could do at the scale of several km. I think it fits the philosophy of the game and my vision with the large solar system. I think we should do it. What is your feeling on that?

While the scale of the game alongside the potential would be massive, my main concern is how long this change would take - the game had some rather dark periods when we switched from singular blocks to stretch tech. Also, the game had nearly every build break and nothing was built for months - would we be able to keep our ships? Otherwise, I like this idea, I want to have a lot more FPS please

[ultrak2k]

What stuff would be impossible though?

[ZachZent]

NEO-VOXEL HELL YEA!!!

One question though, how will this impact NPCs? I've always been on the fence with full NPCs on every ship since as you said NPCs would only work with the block grid where most players use blocks and bricks

[tsunamayo]

@ultrak2k actually I want to do that change to simplify my code. I would make sure that each build are carried over, I have done worse conversions in the past I am not worried. Only think is that a lot of 1m decals would be spawned where you used voxel paint. Code wise I am almost there on the physics aspect. I would need to work on balancing though. I would still need to convert the light as it is still using a big chunk of memory before we can get to mega build though.

[tsunamayo]

@ZachZent so I would have to find a way. But looking at how people are having a hard time with the grid (for light or else) I think it would be better to not be limited by that. Most game are not using a grid btw, but a nav mesh, which would suit my requirement. I would look into that first. Also pathfinding is not that critical, it is not a strategy game. Air pressure was another nice thing to work with grid, but again as people are not complying with grid it is better to do it another way.

[ProPeach]

Wow, what a huge potential change! I'm pretty excited about this, but it's so different I can't help but be a little apprehensive :D When you say that a non voxel brick could be placed anywhere, would that mean you could enable/disable snapping to a grid while building? Obviously with no voxels there is no real "grid", but it's having no ability to align would be troublesome.

Do you think this could effect the performance of static and moving child entities too? Would this allow a larger stretch limit? I know previously you said it was hard coded, but it sounds like this is a whole new board game! How would damage work without the voxel system? Very excited to see how this goes!

[Kaiser-Indrasil]

Honestly, this is the pivotal point for Starship Evo. I've never been more excited about the game's development than now.

Voxel damage. I think that system was working well, except that it is a huge pain in the ass to work with. But that would mean brick and hull would be unified (they would be the same really, except for the size and their base property).

What do you mean by their base property? Sticking to the 1x1x1m voxel grid or something else?

Also, what about light bleeding through the brick walls? Do you think it would be possible to get rid of it thanks to this update?

[ultrak2k]

Would survival still be ship size limited? What was the original reason for that

[tsunamayo]

@Kaiser-Indrasil so I meant mass and hull point. Light is a different tech, yes I would need work on that. Either moving away completely from voxel and try shadowmap, or using a voxel grid per light, and building the connectivity grid with raycast (making it compatible with brick). That is what I am doing with the collisions points. In any case (whether I do the voxel kill or not) I need to refactor light... @ultrak2k no not really, although the physics will start to not work if too big (not sure at how much just yet) @ProPeach yes correct, I think having a grid for block is essential otherwise they are too painful to position. But I could always add an option to deactivate it (I am think about a building option menu lately). Stretch limit is still limited because of the way bricks are packed, I think x16 is decent when the upper size is x4, it gives good coverage. But I could be refactoring this. Oh I am just thinking about this, I could have 24bits color per brick now (big issue was really voxel memory). I am not making promise I need to look into that. Damage would be proportional to hull stretched with a malus of some sort I guess or a penetrative mechanic.

[ultrak2k]

Well honestly if builds will be ported, and we gain more freedom, which is what much of the community yearns for, then I see this as being a popular change - especially if it secures valuable performance critical for a space game that will ideally have fleet battles.

[Kaiser-Indrasil]

This about sums up my feelings towards this change

Thanks, @ZachZent

[SageThe13th]

Given that I and many people would like to see large battles between large ships. It seem like the pure stretch tech is the way forward.

[TripleHelixxx]

Sounds promising. I say go for it. I am curious about which things would be “impossible” though.

[ultrak2k]

You mentioned a ring of bricks, but how would terrain be affected by this? Could terrain be made to lag less as an example? I’m not sure what it entails terrain wise and destruction of it wise but I’m excited anyway

[Vicomt]

I'm quite excited about this, but I'm wary on a couple of fronts. from previous conversations, we've determined that it's been the lighting textures that have been limiting size on larger builds, and indeed, the current shadow distance isn't even big enough to cover large builds. If you're talking about larger block sizes, how are you going to cope with the increased lighting/shadowing requirements or is the current shadow range all we're ever going to have?

this sort of thing is what I'm talking about

which is a view down the hangar on Leviathan. the self-shadowing stops about halfway down.

[Garrett-C]

I am really excited for some of the advantages this change would have but I am also sort of unsure about the exact details.

How exactly will this change how we play the game going forward? How will this change the act of physically building ships? Given that you said that it won't break old ships does that mean that everything we are able to do now will still be possible (with the obvious exception of the paint)?

That said when it comes to paint and this new approach I am a little sceptical. Does this mean we would need to paint each face of a block in the future? That doesn't sound like the most intuitive system at all. I would assume you just paint the full streched block, which would honestly be better than the current system if you ask me.

Also some other thoughts. Could the death of voxel building perhaps lead to the ability to build on slopes? I appreciate this is maybe a big ask but the new system does make me wonder.

Overall I do think it sounds like a really promising direction for the game, just makes me feel a little cautious about what we may loose for it. Would be nice to see some actual examples of what it will be like.

[Briaireous]

Does the small border refer to the borders of bricks that we use to make the paneled look of armor slabs?

[TIKIRobo]

for the paint thing as long as we can stretch the decal to at least 16x16 id be fine with it, the only problem i have is some decals rn like to "clip" through blocks making the decal appear on both the decal-ed surface and also whatever surface is below it

[ProPeach]

Petition to name BFBs Big Fantastique Blocks 😄

[Xerma]

I personally don't see a whole lot of downsides to the potential switch here. We wouldn't have to give the same ol speech to new players about size limitations. Painting would be something to get used since it would be just how we deal with bricks by breaking up larger surfaces into smaller sections. As for pathfinding I'm sure there are multiple ways to get it to work. - One off the top of my head is just another tool to create areas to indicate where the AI is able to move (like building blocks but no rendering and no player collision) But that already has its pros and cons there.

The one true downside of this is now that we heard about it some players, like myself, might get that feeling of "Should I build now or wait to build with the big blocks?"

[Regnion]

If you're going to make large scale, foundational changes, it is better to do it sooner than later. However, you should also consider putting out a solid roadmap of development. The game's playerbase has been dwindling by large amounts over the last few months, with a spike in September which may have been a sale? Fewer and fewer people are browsing and uploading to the workshop, fewer are playing the game.

How long will this change take to implement and complete? If the change to this non-voxel system is going to take months, how much longer for smaller quality of life fixes we've been waiting on for years, such as new glass, more stickers (number decals, letters, etc), turret blueprints? How much longer until our first survival elements? We have fuel tanks after 4 years of development, but no fuel, nor a means to make fuel. No cargo containers or inventory system. We have a first pass at a chip upgrade system but it doesn't actually accomplish anything since there is no crafting system.

Again, foundational changes should be done sooner rather than later. If it improves performance and ultimately enhances the gameplay and creative freedom, then I think it's the way forward. However, I highly recommend you draft a letter that details what direction you're taking the game going forward, and provide a rough roadmap of features (no timelines, avoid those), and write it for both new customers and your long-time followers. Not just a quick and dirty github post, a thorough explanation of what direction you're taking will appeal to many potential customers and also help address some concerns about the pace of development. You are your own boss, you set your work pace and determine priorities, however the ship can't be rudderless. The game is for sale and few actual gameplay features exist beyond building, and now you're going to make massive changes to that system. I have total faith in you, since 2017, however I would like to know what your plans are going forward.

[Dwarf-LordPangolin]

I have several thoughts on this:

1. Regardless of whether this is a good idea or not, I don't think you should make any changes that require a significant investment of time until there's at least a basic but complete gameplay loop in place. If this is something you can implement without appreciably slowing the development pipeline down, then the pros and cons of it require consideration, but I worry that the game will become seen as vapor-ware if there's another ... what was it for the previous refactor, 6-month delay? If implementing this would take less than a month, the points below apply, but otherwise I think the idea should be shelved until later.

2. Scale. I gotta be honest, I don't really want larger ships. I'm currently working on a 200m ship, and doing the interior is going to be a Herculean task. The reason isn't that the blocks aren't large enough; the reason is that the level of detail per cubic meter is very high. Making larger blocks won't change any of that. I likely won't be building ships that much larger than I build now; the Baltic in SE (~350+ meters IIRC) was the biggest I've ever gone for, and I never finished that one. Being able to build super-size ships isn't something that interests me. I just don't care if the ships in the game can get super-big, since I'm not going to really use that feature (edit: Regnion reminded me of how useful the large blocks were for making stations, so I actually would find use for this with those). So, jumbo-sized ships are uninteresting to me, and potentially annoying if a lot of the stuff people make on the workshop is stupid-large. I really don't want the game's battles to turn into 2 super-large ships dueling each other; I'd much rather be able to have a lot of normal sized ships fighting each other at the same time, which is more of a performance issue. Which leads us to ...

3. Performance. If this would improve performance for the current-sized ships, that would definitely be a reason to consider this; ditto if it helps the coding side (that's desirable in its own right, doubly so if it makes future development easier). It sounds like this would have a pretty hefty performance improvement, both in terms of FPS and memory, so that's a very definite plus. By itself, that makes this very interesting.

4. Grid. I'm glad that the 1m increments would be kept, because those are essential, particularly for players that are newer to this genre of game. 50% of the reason I don't play Avorion, despite buying it, is that it's virtually impossible to keep things locked to a grid, and that drives me bananas. It also sounds like painting would be faster, which would be a very nice QOL improvement. It would also be convenient to be able to place things more freely. It sounds like this might also make airtightness simpler, which would be good.

5. Voxel damage. As noted, we would lose voxel damage. It sounds like damage would simply involve the deletion of whole blocks -- this is how Avorion handles damage. I really don't like this, for two reasons. First, it means you can't really poke a small, fast hole in the hull of something if you need to. That's not just a combat thing; sometimes for whatever reason, especially in survival, you just need to make a hole. Having to destroy a 5x10x2m chunk just to make any kind of hole really isn't appealing. Second, Avorion's damage just looks really derpy; it looks a lot worse than the damage model SEVO has now, because it's not granular. You can usually very clearly see what size and shape block was destroyed. When I built Avorion ships, I actually used more blocks than I needed to, so that any holes that appeared in my ship weren't enormous (and didn't expose huge chunks of my internals). I would probably do the same thing in SEVO; I wouldn't want any hole in my hull to be larger than 10x10m, so I probably wouldn't make any blocks larger than that. So if you do this, people might not take full advantage of the ability to stretch blocks, and you might not get as much performance gains as you'd like. I'm not a fan of losing voxel damage. A penetration mechanic would alleviate some of the problems with this, but I still don't like the idea of this. However, if the destroyed blocks didn't just completely disappear, but instead had an effect applied to them that made them look like they were scorched, banged up, and full of holes, the aesthetic concerns would be removed. That would look pretty cool.

6. NPCs. You said that "Also pathfinding is not that critical, it is not a strategy game." I must disagree a little; I'm pretty much only really going to play this single-player, so having a world that feels alive is essential. I'm tired of playing games where it's obvious that the only character that can go and do things is the player. Ships with NPC crew were one of the big selling features for me. So, having a viable plan that would work at least as well as it would have with voxels is a must-have, otherwise this is would be a huge step back. On the other hand, if this would make NPC pathing easier, then that's a huge plus.

7. Terrain. This is a bigger one than the amount of attention it's gotten in this thread, because it sounds like this would affect planets as well as the ringworlds. I don't understand what this means: "I could replace the rings by a bricks based entity, again simplifying my code and leveraging on the community ability to make me good looking, large and varied stations instead of spawning the same ring everywhere." Would we lose ringworlds? Because I really like those. Or would their terrain simply be made using a more performance-friendly technique? I'm honestly OK having rings of the same size and shape everywhere, as long as the terrain isn't the same, and they have interesting stuff to make exploration worthwhile. Also: I don't know how many habitats you'd get from the community. That sounds even more challenging than the station modules.

8. Smart border. If this is removed, the blocks need to have the beveled normal effect removed. Being able to have smooth surfaces is a must-have. It would be insanely frustrating to have lines on the hull every place where blocks meet; the lines where bricks meet are already annoying enough. If one of the effects of this idea is that our ships are covered in seams, that's a definite mark against this. That said, if a sticker was also added that could hide those seams and make surfaces appear smooth, that would solve this issue (as well as just being a handy tool in general).

Conclusion I'll probably have more thoughts on this later, but after writing this down and looking at it for a while, I feel like there are three kinds of changes that would result from this:

• Changes that don't matter. A lot of these are probably a lot more significant from the development side of things, but for the end-user, the method used to achieve them doesn't really matter. NPC pathing is one of these; as long as my crewmates can get from Point A to Point B without getting stuck in a door like Lydia in Skyrim, I don't really care whether the pathing is voxel-based or nav-mesh based. That said, these are only non-issues if they don't harm intended features; if they do, they become the next kind of change:
• Changes that would be bad. Again, I'm not a huge fan of losing the voxel-based damage; if the new system would end up like Avorion's, it's not going to look good, and I'm not a huge fan of the kind of enormous, yawning chasms that your ships end up with in Avorion; again, they expose a lot of the interior, and that's terrible, so to prevent those kinds of exposed areas a lot of builders will just end up using more blocks to cover the same area -- which negates at least some of the performance gains.
• Changes that would be good. And the obvious one there is the improvements to performance this would grant.

The mantra that I used to annoy people with on the Space Engineers forums is: gameplay is king. And I don't think I need to tell anybody here that performance is vital to any game, and particularly the kind of massive game that SEVO is, where people will be very disappointed if there aren't large space battles in massive environments. People will be willing to overlook a lot of other issues with a game in this genre if it plays smoothly while they recreate the kind of large battles they see in movies and games that don't feature building. So, with that in mind, my conclusion regarding this idea is as follows:

If this would significantly improve the performance of the game with the current size ships, this would be a worthwhile change, provided it can be done without significantly delaying development. If this would delay development significantly, it should be postponed until there's at least a basic gameplay loop.

[Kaiser-Indrasil]

@Dwarf-LordPangolin

Scale. I gotta be honest, I don't really want larger ships. I'm currently working on a 200m ship, and doing the interior is going to be a Herculean task. The reason isn't that the blocks aren't large enough; the reason is that the level of detail per cubic meter is very high. Making larger blocks won't change any of that. I likely won't be building ships that much larger than I build now; the Baltic in SE (~350+ meters IIRC) was the biggest I've ever gone for, and I never finished that one. Being able to build super-size ships isn't something that interests me. I just don't care if the ships in the game can get super-big, since I'm not going to really use that feature (edit: Regnion reminded me of how useful the large blocks were for making stations, so I actually would find use for this with those). So, jumbo-sized ships are uninteresting to me, and potentially annoying if a lot of the stuff people make on the workshop is stupid-large. I really don't want the game's battles to turn into 2 super-large ships dueling each other; I'd much rather be able to have a lot of normal sized ships fighting each other at the same time, which is more of a performance issue. Which leads us to ...

Just because you don't want to build enormous ships, doesn't mean that other people don't. Be inclusive. Also, the change would boost performance for all the ships, not only the big ones.

Grid. I'm glad that the 1m increments would be kept, because those are essential, particularly for players that are newer to this genre of game. 50% of the reason I don't play Avorion, despite buying it, is that it's virtually impossible to keep things locked to a grid, and that drives me bananas.

It IS possible to grid-lock blocks in Avorion. You just have to set desired grid distance.

Voxel damage. As noted, we would lose voxel damage. It sounds like damage would simply involve the deletion of whole blocks -- this is how Avorion handles damage. I really don't like this, for two reasons. First, it means you can't really poke a small, fast hole in the hull of something if you need to. That's not just a combat thing; sometimes for whatever reason, especially in survival, you just need to make a hole. Having to destroy a 5x10x2m chunk just to make any kind of hole really isn't appealing. Second, Avorion's damage just looks really derpy; it looks a lot worse than the damage model SEVO has now, because it's not granular. You can usually very clearly see what size and shape block was destroyed.

Currently, bricks distribute the damage along the voxel grid and the damaged sections are physically removed which means you can go through them. I don't see a reason why this is wrong. The only thing lacking is the cross-section you can see on damaged voxel blocks. Peach helped me realize that this system is also voxel-dependent, rendering my point invalid.

Smart border. If this is removed, the blocks need to have the beveled normal effect removed. Being able to have smooth surfaces is a must-have. It would be insanely frustrating to have lines on the hull every place where blocks meet; the lines where bricks meet are already annoying enough. If one of the effects of this idea is that our ships are covered in seams, that's a definite mark against this. That said, if a sticker was also added that could hide those seams and make surfaces appear smooth, that would solve this issue (as well as just being a handy tool in general).

It's trickier than this. Seams exist to hide sometimes misaligned textures on neighbouring surfaces. I'm sure you've seen this in Avorion. If they were removed, those misaligned textures would become more apparent, which wouldn't look polished.

[Kaiser-Indrasil]

Damage would be proportional to hull stretched with a malus of some sort I guess or a penetrative mechanic.

Ok, @tsunamayo what is a malus in this context?

[ultrak2k]

The whole "We shouldn't have big ships" because then people will use them overpowerdly is a terrible argument against people's right to build what they want in a building game, because there's ways to balance against large ships besides them not existing, look at fuel and limited throughputs, as just one example. While I absolutely agree that smaller ships should have a place and I believe they can, it's unfair to abolish big ships because you don't like them, and I'm not a big ship builder.

[tsunamayo]

@Kaiser-Indrasil my 3yr old saw this pic and told me, "So you have been there? Thats cool!!" Didnt mentioned anything about the hulk body though...

Thanks all for your feedback. One big question is: how long this is gonna takes? It is a bit complex:

• Lately I made big progress toward a complete custom physics collision system (before I used an inefficient mix of Unity + custom). The broadphase is done (which entity collide with which), but I can now unplug my voxel code and use the same tech for the narrowphase (which brick are you colliding with) for simplicity. I want to do this anyway because: it would yield massive memory saving and allows me to offload physics code to other thread, making it free. This I will do anyway, and it is near completion (will be at the end of the day). The only think is if I need to keep voxel it would take much more time as I need to make it fit into the new code. => the switch is making me save time here. I was convinced after I lost 2h exploring ways to integrate voxel into the new framework the best way possible. At the end it hit me, lets just get rid of it! I have been carrying too much complex code for little upside.
• Now I would need to convert your build. I have done worse many time in the past it should not be too hard.
• I would also need to work on the new hp system. It is not the end of the world as the new system will be a lot simpler. This goes hand in hand with the save conversion as it would require a new format (I need more room to store the hp value)
• Clean all the current unnecessary code. Thats several classes and thousand line of code. The best part, cant wait to do this.
• Now to really allow mega build I will also need to unplug the current light system. This was on the to-do list anyway.
• Space habitat (use of terrain in custom build), this will take a lot more time to get there, as it is not super high on the list. I would like get something dirty so that some people can make me habitats before having something usable by everybody.

[Kaiser-Indrasil]

Sounds like the switch would actually save you more time than sticking with the voxels in the long run. I like that.

[tsunamayo]

@Regnion thanks for reminding me ;) I know I have been slow, believe it impact me more than you do. I dont like much the roadmap idea I dont want to sell the game by making promises. It could generate frustration on both side and backfire. The only item in the roadmap really is gameplay. The spike in player correspond to a few youtubers making videos about the game. I am waiting to have more content before doing a real push PR wise. @Dwarf-LordPangolin . 1)Time: So I do this to actually gain time long term. There would be a bit of conversion work to be done, but definitely not that long (few days). Then the light refactor will have to be done to really do large build, but I had to work on that anyway. Again this would be a big memory boost, allowing for more NPC ect. 2) Scale I am also not a fan of mega ship. I dont really plan to add mega-ship for the solo campaign. But for sure people would want to design large ships. I wonder if it would kill a bit the aura around massive ship when they would be so easy to do (in creative)? Like what is the point of 2km ship if anybody can do this? I guess some people could actually be upset that their 500m behemoth will be dwarfed by a 2km one that took 100x less time to do. 3)perf. There will be small boost (dont expect 2x boost though) in pixel shader. Loading time will be faster. 4) grid Yes this is a must have, I might give the option to disable it though. 5) Damage I know it sucks, but I was thinking of the opposite, people wanting to build large to make piercing harder! For the detaching part I actually though it was going to look cool. I think we would need to test. If it dont look right I can have them stay in place and use a destroyed mesh instead... We have options, so I think we will find something right. Having to destroy a 5x10x2m chunk just to make any kind of hole really isn't appealing. =>But that is the case for now already, sure you can destroy (with weapon) a voxel, but you cant build inside and will get the destroyed texture on the sides. I know this is a drawback compared to voxels, but I guess people got used to it. 6) NPC. I meant in the sense that if your NPC are moving a bit randomly, not choosing the shortest path ect it wont be deal breaking like in a RTS as you wont spend your time giving move orders to your crew. But if I manage to build a nav mesh it will work anyway. 7) Terrain. So terrain is out of scope of this. Actually I plan to use voxel and marching cube everywhere (for now only asteroids use that). But that is a different voxel tech. I dont want to remove the ring - I like it too, I just want the outer hull skirt to use brick entity instead of custom code making my life easier. That would make it faster to render too, and more importantly I could use different one made by the community. But I need to give player a way to spawn procedural terrain (Having it non-procedural would mean it would take way too much memory...) 8) border. I know it sucks, I like that border feature too. But I think I can get the new look work. I had a look at your ships, it was not that bad, good looking ships still looks good.

@Vicomt Shadow are a different problem. They are quite expensive so the range is limited. But I will provide higher setting for higher end PC that will increase range.

[Garrett-C]

It all sounds quite positive to be honest. There are certainly lots of questions up in the air though.

Like damage. Does this mean damage would be moving to an entirely hp based system with no destruction? Or would we just see bigger chunks of ships getting destroyed at a time?

In terms of unifying bricks and blocks does this mean bricks will actually have a heat dissipation value? And does this mean we would be getting things like the ability to have pipes going through bricks like they do hull currently?

With the inability to do the smart borders on blocks is your plan to just keep the bevels but make them very small or to remove them to make the border a sort of naturally seamless border? Would it perhaps be possible at some stage for you to share some images of a ship with different levels of the border so that we can see what you are considering?

It all sounds promising and if all we loose is voxel based damage and painting 1m segments without stickers I see it as an absolute win as long as we are still able to do pretty much everything we can now and our current builds aren’t nuked by it then I am cautiously optimistic about the path you are considering here.

[tsunamayo]

@Garrett-C So for damage I still wanted to have per-brick damage. With a first implementation of brick separating, or disappearing, although Dwarf seems to says it looks silly in Avorion so I might just leave a "destroyed" brick instead with a different mesh.

Yes that would mean smaller brick would have heat dissipation and all the rest, but that would takes a bit of time to calibrate properly. That is a big positive point in my view, it is simpler for newcomer and generate less frustration with those eternal brick vs hull block discussions. I will have to make sure to balance things well, aka I dont want people using 0.25cm size system in their 100m ship because thats a more powerful way to go... (again I dont care if they do, what I dont want is them feeling obliged to do so because of the game mecanic!) Also I guess I would have to allow for no clip for pipe, although I need to think about it a bite more to spot any negative outcome.

[Dwarf-LordPangolin]

1)Time: So I do this to actually gain time long term. There would be a bit of conversion work to be done, but definitely not that long (few days). Then the light refactor will have to be done to really do large build, but I had to work on that anyway. Again this would be a big memory boost, allowing for more NPC ect.

If doing this not only improves performance but actually speeds up development time, then that's a definite win! 👍

2) Scale I am also not a fan of mega ship. I dont really plan to add mega-ship for the solo campaign. But for sure people would want to design large ships. I wonder if it would kill a bit the aura around massive ship when they would be so easy to do (in creative)? Like what is the point of 2km ship if anybody can do this? I guess some people could actually be upset that their 500m behemoth will be dwarfed by a 2km one that took 100x less time to do.

I think some of the other posters in this thread misunderstood my post. I'm not a fan of mega ships, but I'm not opposed to people building them either. I just wanted to make sure that it's understood that not all players will be as interested in a huge increase in the max size of ships as others are. So, just like the folks that are fans of mega ships gave their feedback, I wanted that view on the record. As long as the game is balanced and doesn't make mega-ships the only viable meta, I'm happy.

3)perf. There will be small boost (dont expect 2x boost though) in pixel shader. Loading time will be faster.

A small boost is still a boost. And given what you said at the top about a 5km ship having the same impact on FPS as a 50m ship, that sounds like a pretty big improvement to me, particularly if we try to get fleets of ships duking it out.

4) grid Yes this is a must have, I might give the option to disable it though.

Sounds good!

5) Damage I know it sucks, but I was thinking of the opposite, people wanting to build large to make piercing harder! For the detaching part I actually though it was going to look cool. I think we would need to test. If it dont look right I can have them stay in place and use a destroyed mesh instead... We have options, so I think we will find something right. Having to destroy a 5x10x2m chunk just to make any kind of hole really isn't appealing. =>But that is the case for now already, sure you can destroy (with weapon) a voxel, but you cant build inside and will get the destroyed texture on the sides. I know this is a drawback compared to voxels, but I guess people got used to it.

If you can make the detaching part look cool, that'd be awesome; I've only played a bit of Avorion, and that was a while ago too, so my info may be out of date, so maybe they've improved their version as well. At the time I played it just looked very artificial.

sure you can destroy (with weapon) a voxel, but you cant build inside and will get the destroyed texture on the sides

So, the specific examples I had in mind actually was for boarding enemy ships and cutting through doors/walls to get to your target inside, or for when your ship has crashed and you need to get out in an emergency (both scenarios I've run into in Space Engineers). Not being able to build + seeing destroyed textures isn't a problem in either case.

That said, even if the changes to the damage model are less than ideal, a boost to performance + improved development time would justify the cost of that. 👍 And as mentioned above, a penetration mechanic would probably help balance any gameplay changes to the damage model.

Edit: this is an example of what it looked like when I played Avorion. As you can see, it's a fairly jarring hole.

6) NPC. I meant in the sense that if your NPC are moving a bit randomly, not choosing the shortest path ect it wont be deal breaking like in a RTS as you wont spend your time giving move orders to your crew. But if I manage to build a nav mesh it will work anyway.

Ah, I see the distinction you're making. Like I said in the conclusion of my post, as long as they can get from A to B, that's fine by me.

7) Terrain. So terrain is out of scope of this. Actually I plan to use voxel and marching cube everywhere (for now only asteroids use that). But that is a different voxel tech. I dont want to remove the ring - I like it too, I just want the outer hull skirt to use brick entity instead of custom code making my life easier. That would make it faster to render too, and more importantly I could use different one made by the community. But I need to give player a way to spawn procedural terrain (Having it non-procedural would mean it would take way too much memory...)

I see what you mean now; that makes sense.

8) border. I know it sucks, I like that border feature too. But I think I can get the new look work. I had a look at your ships, it was not that bad, good looking ships still looks good.

Like I said, even if this change would introduce some changes that I don't like, if it improves performance (and development time apparently; woot!), then it's well worth the cost. 👍 Do you think it would be possible to add a sticker that can hide the seams, though? Some of us were also thinking that a sticker to make fake seams would be good too; right now we're using the vent sticker stretched long, which works, but it's not quite ideal for that, since the ends stretch and need to be hidden (I use this on the floors of my ships).

[RockefellerDoctor]

My only concern is whether it means having to rebuild my ship designs or not. If I can keep using the ship I built in this hypothetical new build, Im fine with it.

Though I would mirror what someone else said: i would perhaps focus on creating a compelling and stable gameplay loop before putting too much time into revamping building mechanics, as the game is sorely missing any meaningful gameplay outside of just building, as it is progressively becoming more and more clear that people are leaving the game due to there being nothing else to do after they've satisfied their building itch.

[Garrett-C]

@Garrett-C So for damage I still wanted to have per-brick damage. With a first implementation of brick separating, or disappearing, although Dwarf seems to says it looks silly in Avorion so I might just leave a "destroyed" brick instead with a different mesh.

Yes that would mean smaller brick would have heat dissipation and all the rest, but that would takes a bit of time to calibrate properly. That is a big positive point in my view, it is simpler for newcomer and generate less frustration with those eternal brick vs hull block discussions. I will have to make sure to balance things well, aka I dont want people using 0.25cm size system in their 100m ship because thats a more powerful way to go... (again I dont care if they do, what I dont want is them feeling obliged to do so because of the game mecanic!) Also I guess I would have to allow for no clip for pipe, although I need to think about it a bite more to spot any negative outcome.

Yeah that’s fair.

I mean on the per stretched shape breaking I can see how it could be a little odd. Like if you chose to add the 64m blocks for example then those could potentially stretch to over a 1000m assuming the 16x stretch is maintained and yeah I can see how a block bigger than most current ships just disappearing could be considered kind of undesirable.

I agree the unifying of bricks and hull for things like heat and pipes etc should make the game way more intuitive for new players. It’s certainly one of the majorly beneficial parts of the change from a gameplay sense.

So in terms of building. Would building still be done in a sort of voxel sense in that it would conform to a grid or would the building be much more freeform? I.e you can place a block anywhere on a face of a block?

[tsunamayo]

@RockefellerDoctor I would upgrade blueprint on load, like I did many time in the past. These is quite a structural change, this must be decided now as I am finishing the physics refactor. It will take me more time to finish if I still want to use voxels. Both options are similar in term of time cost on the short term, but the voxel kill is making me gaining a lot more time long term as it is less code to manage.

[tsunamayo]

@Garrett-C nope I still need a grid and a rotation lock. First there is a space one as each brick is storing its position and orientation, it would takes a lot of space size to store everything. Then there is the grid issue. Say if you build at a slanted angle, then want to put another brick on top: you can no longer build at the original grid as it wont align to the new brick. I dont think that would be a good change.

[Garrett-C]

@Garrett-C nope I still need a grid and a rotation lock. First there is a space one as each brick is storing its position and orientation, it would takes a lot of space size to store everything. Then there is the grid issue. Say if you build at a slanted angle, then want to put another brick on top: you can no longer build at the original grid as it wont align to the new brick. I dont think that would be a good change.

Ah so when placing and breaking blocks the change would basically unnoticeable it’s only in the case of things like paint and damage that the change is really felt.

Unfortunate as I was secretly hoping that this could allow for the forbidden art of building on slopes but yeah as you say it’s honestly much better to maintain the sort of grid based building. Plus it does mean that in many ways the change is less noticeable which is fair.

[tsunamayo]

Okay I made a few comparison screens with a few differents borders: No border, Light normal, but strong color, Medium normal, full normal => normal = 3d effect, end look it will depends on the shadow. Aka sun perpendicular has little impact, while near parallel sun will be very pronounced.

https://imgur.com/a/WX2cjq2

[SageThe13th]

I always preferred the flat look without borders. Not unlike what the first released of Skywanders looked like. The boards have always kind of annoyed me. Especially on bricks.

[ultrak2k]

Honestly the flat no border look looks real good to me

[Garrett-C]

It's a tough one if you ask me. The ones with borders look better in the first example in my opinion but in all the other examples the no border look is nicer I think.

[ProPeach]

Thanks for the comparison shots! They're extremely useful, although maybe the first image looks very fake because the sun is almost directly behind the camera. No borders might look better with some crisper or better defined shadows.

Would it be possible for the "a bit more normal, a bit less colour" level to have a smaller bevel/chamfer? A bit like the change to brick borders that went through recently that halved the "width" of the border. The borders in the comparison shot somehow seem a little fuzzy in the when toned down, maybe a thinner, light border would help with that.

If that doesn't work out, I vote no borders

[Regnion]

I feel that "no borders" is by far the best option, especially when dealing with angled areas like you identified, but I would ask you give us more stickers that look like lines, panels, and plates, so we can make our own "borders" where and how we wish.

[Xerma]

I personally would like to see more examples of the no borders option. Preferably different lighting examples on different ships. That paired with more stickers/normals would be a very good combo

[Kaiser-Indrasil]

The seamless version looks surprisingly good, especially since the armour texture is so unassuming. I'd say this is the way to go. Perhaps surprisingly, I would love normal map stickers to create our own seams but only when and where we want.

The current seam sticker we have is okay but it isn't easy to work with because it's smaller than the brick grid. It's okay to fake things like vents but for seam stickers I've got another idea:

Crucial thing here would be to align the seam's ends to the brick grid so that they make a continuous line. The seams end in half circles to make as seamless (heh) transition to the next line as possible but for the circles would get elongated if the sticker was stretched, which would ruin the look.

That would need another kind of stretch tech... or, a faster solution which would be a tiny circular seam just for the purpose of making the seams connect seamlessly. A seam node of sorts.

[Uncle-Ulty]

Could we get two types of bricks? with and without borders? A lot of people (me included) use brick borders as tile and wood.

Or, maybe a decal that works eliminating borders? I like borders in some cases, and hate on others, it would be good if we had an option to chose.

some images of borders:

[Dwarf-LordPangolin]

After looking at your example screenshots Tsuna, the borderless version looks better when looking at the ship as a whole. However, when looking at the edges, the bordered version looks better. The problem is that when looking at a ship, the edges are only a fraction of the overall impression.

I think the reason a lot of people like the borderless version is that the borders between the blocks break up the lines of the ship; we try to use the physical shape of the ship to define its look, but the borders disrupt up those lines.

So, using one of those pictures: borderless blocks allow the physical lines and the paint choices of the ship to establish the visual impression, which is basically this: The physical shape, the choice of paint color, and the deliberate use of decals all contribute to define the visual impression. In particular, there are a lot of parallel angled lines that reinforce the overall impression of the ship, which is angular and aggressive. Now, here's the same picture, with borders: All that work has been disrupted by the borders; it's a visual mess. It's like if someone took the Venus de Milo and drew a grid over the whole thing: all the lines are broken. Conversely, for something like a wooden floor, the borders enhance the visual effect; you want a grid for something like that. I actually like the way the brick borders make the underside of the Mistral look like it has something like the insulation tiles that the space shuttle used. But they also disrupt the lines elsewhere on it.

Or, maybe a decal that works eliminating borders? I like borders in some cases, and hate on others, it would be good if we had an option to chose.

I am in agreement with a number of others here that have made the same request; decals that can hide the borders & make fake borders would be ideal. A version with the borders will work (since they do make the edges look better), if there's a way to hide those borders where they don't look good.

[tsunamayo]

@Dwarf-LordPangolin Interesting contribution. Actually I was think about the opposite in way, when zooming onto a detail some border looks out of place and distracting. But when looking at the ship as a whole they are not bad, and definitely add to the believability of a ship, after all they are supposed to be made of hull, and that is exactly what it look like. I do not like the bare look, it just too bare... The end of 5URG3 Destroyer was the worse spot I saw during my test, this is why I included it. It is not looking good because the decals used does not look good with the border on top, and also because of the light condition (near-parallel sun) Here is another angle, medium normal, with a less harsh light.

I tested the border killing decal, it was not working for a very technical reason (anti-aliasing). I could try another approach, but it wouldnt not work for border on wedge, unless I do some bigger refactor of the decal. The issue is that the original normal (without the border) is not known to the decal when it is applied.

Cheers

[Regnion]

Here's some border gore worthy of the Balkans:

[Click here]

  

I would rather have the bare, smooth surface, and decals that allow me to draw lines and place boxes similar to the triangles and circles we already have.

[Garrett-C]

I mean I would argue the most ideal solution is a paint that can add the bevel if wanted but I can imagine that it wouldn't be possible due to data storage issues with the blocks.

Having a border and non-border variant would be nice but that would clutter the codex/hotbar and would raise issues with the conversion of ships.

I think on the whole the flat look is nicer, but the border can be very nice situationally.