next »

[jgrams]

Let me know if this kind of post is interesting for you (more details? less details?) and I'll try to write some more.

I'd be fascinated to hear a little bit about what approaches you've tried for vertical bits of track and what the problems were.

e.g. I'm guessing you tried taking the up vectors on either side of the vertical bit, interpolated and "re-perpendicularized"? A problem because you have to compute the others and then come back for the vertical parts? Or if you have a track which corkscrews down it could fail due to the 180-degree singularity in the interpolation...?

This stackoverflow question looks pretty interesting -- start with an up vector, then step along the curve updating it at each step. Seems to join up properly if you loop it (cool WebGL demo; drag left/right to rotate the "track", click the camera view button to fly along it).

And this SO question is about getting normals in the plane of the curve at that point. Which is probably not what you want, but the math is fascinating.

[Sebioff]

Sure! Here's the ones i can remember/still have code for.

First of all I made a small track for testing purposes:


There's a discontinuity at the loop entrance/exit but it doesn't really matter as all methods failed before that.

The first method you linked is attributed to Ken Sloan - I couldn't find where it's originally described but it's mentioned in a couple papers on this topic.

Note how the normal gets tilted in the curved downward slope, that's not what I want.

Next I tried this method but couldn't make it work - no idea if I did something wrong or there's an error in the formula.

This method gave me the same results as Sloans.

After a bit of thinking I came up with the following method that works for me (except for the loops, but I can threat those as a special case):

Code:

// t0 = previous tangent, t1 = tangent at current point
// binormal should always be parallel to ground (passengers shouldn't be tilted around the tangent), I don't care about change in vertical direction
t0.y = 0;
t1.y = 0;
// get the angle between the previous and current tangent
float angle = Vector3.Angle(t0, t1);
// get an axis defined by these tangents that we'll use to rotate our previous binormal about
Vector3 axis = Vector3.Cross(t0, t1);
// b0 has to be defined for the first point of the curve (manually, using Sloans method, using the world up vector, ...), afterwards it's transported along like this:
Vector3 b1 = Quaternion.AngleAxis(angle, axis) * b0;

[Munkyman587]

Can't express how saddened I am to see the dev logs die after your kickstarter.  It is like you most loyal fanbase is now an abandoned black hole....

Edit:  Before you say anything, or mention "kickstarter backer bonus!"  ...dude, look at the last post date in this forum.  It is simply depressing.  Give us *something*

[JobLeonard]

In their defence, except for one post in mid-November and a handful of backer-only updates (likely to involve genuinely backer-only stuff such as "how to get your merch") they haven't updated their kickstarter page either.

[deanr201]

Hopefully the Dev's dont mind. but to save them a job.

Copied from: http://devlog.themeparkitect.com/

Update 22
http://themeparkitect.tumblr.com/post/104611302547/update-22
Gordon delivered a bunch of new sound effects this week, which is always a joy. He also made some great progress on the first song for the game. Here’s a (non-final) preview:

The remaining builder windows (terraforming, deco, path items) have been implemented, so everything we have in the game so far is controllable from the new UI system now. There’s still a lot of work left until everything is cleaned up and working as you’d expect but I think we’re slowly switching our main focus back on game features now.
There’s been some progress on the banking angle UI:


We can put limits on banking angles (the grayed out part at the top) which will be needed depending on the type of coaster you’re building. There’s also a yellow fill indicating the delta between this segments angle and the angle of the previous segment. It’s purely cosmetic for now but should become more important later on.
…oh, and here’s some wobbly trees as an excuse for the lack of more exciting gifs this week.
http://media.tumblr.com/c98241862d15cd6a74c296c9c49f4725/tumblr_inline_ng81cwIG0v1si3zx7.gif

Update 23
http://themeparkitect.tumblr.com/post/105167474607/update-23

One goal for this month is to resolve the biggest remaining annoyances of the coaster builder - first and foremost on our list was adding the build previews for the initial station tile and the entrance/exit:


It might not seem very exciting at first since these previews look just like those of any other buildable thing in the game that you have seen on this blog a couple times before, but since coasters work a bit differently from everything else they’d been missing here until now.
It also means we can build rotated and raised stations now!



Another annoyance was not being able to modify coaster tracks at any position. It was only possible to remove or add new segments to the end of the track. Not anymore:



The track builder UI got some new options since Update 21 and is still missing a couple more…it’s getting a bit cramped maybe?

Speaking of UI - trees have color variants now:

Unlike rides for which colors can be freely chosen these have a predefined set of colors (since this is a bit easier to use and it wouldn’t make much sense to give them any color anyways).
There’s also a new set of rocks that I like a lot:

I’m really satisfied with this week, it feels like we got a lot of useful stuff done

[Sebioff]

Can't express how saddened I am to see the dev logs die after your kickstarter.  It is like you most loyal fanbase is now an abandoned black hole....

Edit:  Before you say anything, or mention "kickstarter backer bonus!"  ...dude, look at the last post date in this forum.  It is simply depressing.  Give us *something*

Oh...I guess I somewhat mentioned it but didn't communicate it too well, so let me explain!
I think it was sometime before the KS when we were told by many people that they're interested in the devlog but they didn't really want to have to search for it in a forum/sign up for a forum to be able to follow it, so we moved the devlog over to Tumblr to make it easier for them:
http://themeparkitect.tumblr.com/

I've regularly been posting a new devlog entry over there each weekend since then.
The Kickstarter page we're updating with longer posts at the end of each month - these updates are mostly summaries of the devlog entries and sometimes smaller previews of WIP stuff that are usually posted to the devlog a couple weeks later once they are a bit more finished.
So, we didn't just disappear after the KS or anything like that Development continued at the same pace as before and the progress is still being posted publicly.

Why didn't I continue posting here then? Well, I thought posting the same stuff in two different places is redundant and assumed everyone from here transitioned over to the new devlog. Apparently that was a mistake!

As a rough summary of what's been going on (for details please see the Tumblr devlog), the biggest things have been:
- Remade the guests; their design changed slightly, and they can have different clothing styles and skin colors now:

- All their animations have been remade as well:



- Especially over the last 1-2 months UI implementation has been a huge topic


And a bunch of smaller stuff, both polish (mostly how you interact with the game - controls, camera, building) and features (coaster corkscrews, block brakes, additional slope angles, slope transition scaling).






As for the overall state of the game, I'd say that the content that's been implemented so far is now fairly stable and useable. On the other hand there's obviously still many major features and content missing and it's still an unbalanced sandbox. We won't run out of work anytime soon.

I want to apologize for the silence in this thread over the last few months. I'd very much enjoy actively posting over here again but I also don't have enough content available each week to feed both Tumblr and this place with different updates.
So for the future, should I paste the devlog entries over here? Or just the URL to the newest entry as a reminder that there's a new one?

[Munkyman587]

My apologies, I didn't realize. I appreciate the info and I will update my links. Thanks!

[deanr201]

Copied from http://devlog.themeparkitect.com/

Update 24
This is Update 24, so I guess this marks half a year of weekly devlog updates. Yay!
The coaster builder received highlights for the currently selected segment this week, making it much less confusing to understand what’s going on:


And it’s finally possible to adjust the speed limit of brakes, so we’re really using every last bit of space in this window now:


Block brakes can optionally act like normal brakes and slow the train down to a specified speed if the block ahead of them is clear or not brake at all.
Shops and flat rides received grid lines highlighting the ground tiles they’re being built on which both adds to the blueprint look we’ve got for build previews and can be helpful for raised building:


Niveks suggested on our subreddit to allow scaling up the rocks from Update 23. Nice idea!

[JobLeonard]

Thanks for copying your updates here!

Nice bit of juicyness with the boulder drop in the last image. Details like that make a world come alive

[Noogai03]

Thanks for copying your updates here!

Nice bit of juicyness with the boulder drop in the last image. Details like that make a world come alive

you guys are ludicrously good at making stuff juicy

[Sebioff]

Thanks for copying your updates here!

deanr201 offered to copy them - thanks dean!

you guys are ludicrously good at making stuff juicy

Thanks :D

[deanr201]

Update 25
Hope you all had a nice christmas!
We took it a bit slow this week due to the holidays, so progress has mostly been bug fixes and minor things.
We talked a bit about having different types of terrain this week, like grass, sand, rocks…the tricky part with that is getting the transitions between arbitrary terrain types to look nice, so I experimented with creating a shader that does that.
It didn’t work too well:





We’ll have to find a different approach.
Another experiment was this UI element with a tip for pointing at something:


This one works really well and is now being used in the coaster stats view:


That’s it for this week. See you all next year!

[Alex Strook]

Just read through the 20+ page, I love this project, and the devlog !

Good luck !!

[danieru]

Well thanks for experimenting with the terrain transitions. You`ve saved me from also wasting hours on the subject matter. I can only conclude that for extreme transitions like desert to grass an artist's hand is essential.

[Sebioff]

Visually that'll certainly give you the best results as you have full control over how the transition looks and if you only have a couple of terrain types (or transitions are only allowed between a limited amount of them) its certainly doable.
If you wanna have a dozen terrain types however that can be arbitrarily placed you'd need so many transition tiles that it's not feasible.

Either I have to be satisfied with having just a couple of terrain types with nice transitions, or many with not-so-nice transitions (if there's a way to do that which doesn't look as ridiculous as the ones I tried), or many without any transitions.

Another method would be Texture splatting which would be quite nice as it basically allows the user to paint on the terrain, but it requires one alphamap per terrain type :/

[Gear]

What if the alphamap was procedural or low-res?

[Sebioff]

The alphamap for texture splatting? If it's low res you get visible rectangular chunks of one terrain type (imagine one pixel in the alphamap corresponding to a couple square meters of terrain, you'll get a noticable grid effect).
Procedural doesn't help since filling the alphamap is not an issue, that would be done by the player (which is what I want).

[Gear]

and you can't have transparency in the shader?

(Caution: I may have no idea what I'm talking about)

[danieru]

Gears, yes you can have transparency in the shader but that requires a texture sample and has a cost.

With that said it should be possible to use only one transparency map even with 255 different terrain types. The key is that a tile could only transition between 1 type to 1 type. This is less general than allowing 4 types to converge at a tile but neither should be impossible. Just use the Red and Blue channels to mark the terrain types and use the alpha channel for the transition. If you sub-divide the Red and Blue channels it could support 4 terrain types converging too.

Perhaps a better option though is to mark the terrain type in the vertex color. This is the method me and the artist have been discussing for Super Battleland's terrain. This will save the alpha texture sample and allow arbitrary terrain transitions at the expense of all transitions being a linear blend.

[Quarry]

The problem that arises from vertex blending is unnatural transitions and also increased vertex count if you want to make the interpolation not look so obvious