Page 6 of 7

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 6:40 am
by Employee 2-4601
Cornflakes_91 wrote:New and fancy and "really different" doesnt mean that its good, though
Unquestionably true, but also not a reason to refrain from experimenting with alternatives to 'tried and true' (and perhaps 'generic and familiar') UIs.

Not to say it's top priority (or if Josh has decided to shut that particular door, then so be it); but for me those experiments were one of the most exciting parts of Limit Theory's development simply because of how unique some of it seemed, so I hope some of it survives in the end result. I recall seeing the possibility of a kind of feedback loop where "thinking outside the box" insights into UI led to new insights into gameplay, etc...

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 2:22 pm
by JoshParnell
Oh I'm sure we'll see plenty more UI talk. Not only do I have a love for building them, but I also recognize that the UI is going to be one of the most critical pieces of LT. All the beautiful graphics and advanced AI simulation in the world boil down to nothing whatsoever if the player can't interact with it all in a natural, fun, compelling way.

Fun UI times are not over :)

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 2:32 pm
by JoshParnell
Silverware wrote:It shouldn't be all that hard. Build an asteroid, then using subtractive brushes dig out a tunnel. Take each of these subtractive meshes and merge them. Instant 3D navimesh. If they get near a side that exits to space the they could follow through the internals.

But I doubt that Josh will bother with that, as I expect most of the combat in LT is going to be basically open space combat.


Oh how you make it sound so simple :P Honestly, find me a robust way to do CSG (union / subtract / intersect meshes; most importantly subtract), and I'll pay you oodles of JoshBucks. I've been searching for a solution to that since almost day 1 of working on PCG mesh tech (i.e., 5+ years). It's an incredibly hard problem. I have never found a library or algorithm that can do it robustly and quickly enough to be viable (in fact, even if we drop the 'quick enough' constraint, I still have not found a solution that is robust enough to create well-formed meshes after many operations; failure due to FP precision is virtually inevitable).

With scalar fields, of course, I can do it easily; so I can still create, for example, an asteroid with a cave cut out of it or a hangar for an asteroid base. But taking a bunch of asteroids and digging a tunnel out of them? I can't possibly crank up the scalar field resolution high enough to get that to look decent (and if I could, the poly count would be astronomical). And again, robust triangle-based techniques just don't seem to be there (yes yes, BSP trees; CSG.js; blah blah...the BSP tree algorithm quickly becomes non-viable due to extremely poor split efficiency. Even with an improved algorithm that removes unnecessary splits, it's still not robust on complex meshes (like asteroids). I've implemented it all before and it's broken my heart many times).

Seriously, someone finds me a CSG library that is fast, robust, and written in C (hell, if it's C++ and open-source I'll port it); and I'll pay hard $$$ for it. CSG is the one painfully-powerful procedural tool that I'm missing in my tech.

(Sorry for the rant, I'm salty about CSG and probably always will be...she's the girl I could never get :ghost: )

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 2:34 pm
by Talvieno
:D I was thinking about pointing that out to him, but the conversation was too far along and I didn't feel like dredging it back up.

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 3:33 pm
by Silverware
JoshParnell wrote:(Sorry for the rant, I'm salty about CSG and probably always will be...she's the girl I could never get :ghost: )


Yeah, CSG itself is very much non-trivial.

The actual statements wouldn't be the hardest thing, it's mostly collision detection on vertices, and line/face intersections to generate new vertices when needed at the edge of parts. It's very much the face modification logic that would be used after getting vertices and edges sorted that would be a real pain.

Unreal 4 however uses CSG, and uses a BUNCH of it for mapping.
It has available source-code too, so you could try having a look at that, and seeing if it might suit your needs.
That is likely the most modern engine using CSG in gaming situations. So very likely it'll be the closest you can get to a good off the shelf option.

https://www.unrealengine.com/ue4-on-github

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 3:44 pm
by 0111narwhalz
CSG... Could you guys expand that? It makes a rubbish search term.

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 3:46 pm
by Talvieno

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 4:35 pm
by thedamngod
Hey Josh,

it is such a pleasure to read your dev logs again. :D
I thought now would be a good time to get out of lurk mode to tell you this. I have really missed your style of writing and reading about all the cool stuff you come up with.
Also, the new shinies are very shiny indeed. I like that :)

Keep up the good work. I am already looking forward to reading the next log.


PS: A little late to the party, but congratulations Talvenio. Much deserved promotion :clap:

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 5:20 pm
by Tusck
Guys, not only do I appreciate this new every few weeks update, I also appreciate the non-technical summary at the bottom of this week's submission. Since I did write some negative posts in the past about the lack of communication, I'm here now to thank you for making this happen in a normal way that gives good steady updates in a way that doesn't drive a one man team crazy.

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 6:23 pm
by Ashenraynor
Excellent screenshots and congratulations on the progress. :clap: :clap: :clap:

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 6:56 pm
by Silverware
JoshParnell wrote:Note: these shots were rendered @ 1080p with 2x supersampling, which is equivalent to 4K res. With the massive performance gains from this week's work, it all runs very smoothly @ 60fps in 4K (!!) resolution with full, 100+ ship battles going on. Keep in mind that only the asteroids are using the perf-boosting entity system, the ships are still using the slow one! I am very pleased with this.



Unholy Jesus.
I missed this tidbit.

Woah.
Nice work Josh!

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 7:53 pm
by Talvieno
thedamngod wrote:PS: A little late to the party, but congratulations Talvenio. Much deserved promotion :clap:

Thanks! Means a lot to me. :D Nice to see you posting again, by the way.

Tusck wrote:Guys, not only do I appreciate this new every few weeks update, I also appreciate the non-technical summary at the bottom of this week's submission.

You're quite welcome, Tusck. :) Your words are much appreciated.

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 8:55 pm
by Scytale
Does this mean FPLT has been solved???????

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 9:46 pm
by Flatfingers
Scytale wrote:Does this mean FPLT has been solved???????

That's really the $187,865 question, isn't it?

I'd be really happy if Josh's level of confidence was at or above 90% now.

Heck, 80% would be great -- maybe still worth some more time on Option Z, but enough to feel good about proceeding with dispatch on content conversion.

I'm hoping the next couple of weeks will see more, and more hardcore, simulation tests added. This is smart engineering; push that machine until it breaks! Find out where the boundaries are.

Re: Friday, March 17, 2017

PostPosted: Mon Mar 20, 2017 10:58 pm
by Silverware
Scytale wrote:Does this mean FPLT has been solved???????

No, it does however mean that the FPLT is less of a problem than it was before.

He wounded that beast, that is for sure. :D

But, it's still a massive hulking figure in the distance.
Hopefully it doesn't hit before Josh can scramble to 1.0