GMC Demo Compo #1 - Entries

Elodman

Member
GMC Demo Compo #1

Entry Submissions

THEME:
DEMO DEBUT


This topic is open till the Compo submission deadline, eg:

January 31st, 2021 12:00 (noon) UTC



Plz. post here your GMC Demo Compo #1 entries

  • create one post per entry and continue editing that post to update your progress ( devlogs would be nice additions! )

  • with a download link, till the Compo deadline

  • mark your posts with a headline like this: YourCategory | @YourUserName [| TEAM: YourTeamName]

Read more or make suggestions, ask about this compo at
https://forum.yoyogames.com/index.php?threads/gmc-demo-compo-1-started-demoscene-code-art.76515/




Happy Creation!






 
Last edited:

Bart

WiseBart
Demo | @Bart | TEAM: 3DByDefault


26/12/2020 - 23:15 UTC+1

It's about time I start to write something in this devlog.

The general idea is to fly through the sky, then dive down to earth straight into the city of New York. Do some "sightseeing". Then finish with a grand finale on Times Square.

I did a first test already:


The model data comes from OpenStreetMap and is imported in Blender using blender-osm, and then gets exported to a buffer using my Blender exporter. Next it is loaded using buffer_load and converted to a vertex buffer using vertex_create_buffer_from_buffer.
The model doesn't contain uvs and I sure won't be the one to uv map let alone texture that entire thing! My onboard GPU also can't handle the texture lookups.
Instead I added a basic effect in the fragment shader based on the z coordinate. I also disabled the green color channel using gpu_get_colorwriteenable.

The current model contains about 1.5M triangles but I'd like to "chop it up" in square areas to be able to do very basic frustum culling. That should help to offload the GPU a bit and hopefully allow for an even larger world.
To help with that, right now, backface culling is enabled and blending disabled for this to be as efficient as possible.

And that's all for now.

04/01/2021 - 23:00 UTC+1

In the meantime I've been doing more work on the latest iteration of my Blender to GameMaker:Studio exporter.
This is work that needs to be finished first so I have an easy-to-use link between Blender and GM.

Last year I got into contact with an old friend of mine who is a great musician and I have the honour to put a great tune of his hand under this tech demo!
And with this, I'll refer to this as a team project from now on, with the coding and visuals done by me and the music done by Pieter from Fundisc (he's not a member on this forum though he's the person who introduced me to GameMaker back in 2002!)
I also came up with a nice team name to use for this compo: 3DByDefault (it's one I've been wanting to use for some time and now seems the right occasion)

The idea for the "sightseeing" part that I described above will be a performance that takes place in the city. People gather at a square/park to see the performance. Large screens everywhere showing the performance live being filmed by a couple of cameras.
And that's where things get interesting from a technical perspective, because... GameMaker can handle this kind of setup these days.
Which is what I tested using this quick test:

render_to_surface.PNG

The idea is the following:
Every view has a camera attached to it. That camera can either be a camera with an orthographic (i.e. 2D) or perspective (i.e. 3D) projection set.
The interesting thing is that a view can also be rendered to a surface by setting view_surface_id to a valid surface.
And that's what the above screenshot shows: a surface with the contents of view[0] (128x128) being drawn in view[1] (1280x720).
This simple test shows this in 2D but it works equally well for 3D.

And that's all for now!

06/01/2020 - 16:45 UTC+1

I managed to get that live camera system working in 3D using views. Here's the result of that:

screens_chars.png

At the moment, the entire scene is effectively rendered twice, so it is very costly as you can see in the FPS. It drops somewhere between 20 and 30.
I expect this is not only the scene being drawn twice that's causing this, but also the texture lookups for the screens.
Though I have no experience with it, I expect a basic form of frustum culling will help quite a bit. Based on the camera (i.e. view) that's currently active.

Meanwhile, I also got added physics to the camera. Box2D is only as 2D as you make it.
This gives much smoother and fancier camera motion:


I did have to lower the resolution to 1280x720 for this to run somewhat smoothly on my system. Already... An integrated GPU is a bit limited in what it can do, unfortunately.
The Radeon Vega 8 that I have is a good GPU to use as a reference, though. I'll optimize this demo to run as smoothly as possible on this GPU.
Any GPU that is better will run the demo smoother.

And that's it for now. Quite happy with the progress!

07/01/2021 - 13:00 UTC+1

I improved the camera. It now supports a vertical angle as well.
The system is entirely set up using Box2D.
The horizontal rotation and movement in the xy plane is based on one instance, the vertical rotation and movement (along the z axis) by two other ones.
It may be easier to explain this using an image:

bitmap.png

Right now, there's only one of these, but there will be more of them to allow for cuts between scenes.
When one camera is done, another will take over after a short cut.

VoilĂ . With that there is another tiny improvement!

08/01/2021 16:00 UTC+1

Today I cleaned up the code. A 3D camera is now an object of its own and has two other object instances.
As a result, it is now possible to add multiple cameras to the scene.
There could be other options as well, such as a more custom camera rig setup, e.g. a camera on a crane arm.
That'll sure look great for live broadcasting of the performance 😄

Here's how it currently looks:


VoilĂ . Once again pretty happy with the result!

14/01/2021 12:15 UTC+1

All right. Back to work on this entry for the GMC Demo Compo.
Up till now I've only exported a single model file, which consists of a more or less randomly defined region on the map.
Thing is, the area that I'd like to cover is way too large and, because of that, I need a way to divide it into parts.
Squares seemed the way to go, though until recently, I didn't find any way to easily convert these to a longitude/latitude representation.
The Blender OSM addon works with such a representation. The text that is copied from the web page looks like this: -74.03460,40.68374,-73.95800,40.74047

Today I came across this site, which has the longitudes/latitudes for any given grid square (a standard called WGS84). Which is exactly what I was looking for!
Zoom level 13 seems to work best and corresponds the most to the order of magnitude I'm currently using.

So... Let's just be lazy if we can when coding. This project takes enough time as it is (and there's only two weeks left!)

Time to export a couple of batches!

13:45 UTC+1

After some testing it looks like zoom level 13 will be too big. Zoom level 14 is more appropriate.
It looks like a square is 2000m x 2000m at that zoom level. It will result in many files, though...

22:00 UTC+1

I managed to get a basic script working in Blender that automatically downloads the model data for a range of OpenStreetMap map tiles.
The data is first imported in Blender from the server and then exported using my Blender add-on.
Here's how the result looks in the datafiles directory of the project:

model_data_files.PNG

Some of these currently aren't exporting correctly yet and they contain only data from somewhere on the outskirts of the city.
If I remember correctly there's a 128MB limit for entries. Hmm, I'll probably have to find a way to circumvent that 😁

That's all for today. Pretty good results.

17/01/2021 - 09:45 UTC+1

The stage is set:

Created with GameMaker Studio 2 17_01_2021 9_15_35.png

Now it's time for people to crowd the park. (Apparently, in real life, this place is called Madison Square Park)

31/01/2021 - 13:00 UTC+1

One hour to the compo deadline and it looks like I won't be able to finish it...
Quite a few things in personal life have been taking up a lot of time and because of that, this project moved down on the priority list.

I'd like to finish this post with the latest I was working on: crowd.
The stage is set, three people and a horsehead are waiting but the performance is currently postponed.
In Dutch this is called "drie man en ne paardenkop", meaning as much as "nearly nobody":



It's been an interesting challenge and, as a programmer, I learned a couple of new things along the way.

And with that, this devlog comes to and end.
 
Last edited:
Top