07/17/2020 at 18:52 •
After many years, the Unity editor was apparently ported to Linux. We'll see if it's another 1 & done like Main Actor, Microsoft Word, Internet Explorer, & Skype were. It requires a unity account of course & an internet connection for license management. After discovering how much would have to be programmed from scratch in Godot, the lion kingdom started viewing Unity tutorials. It has a whole lot more examples than Godot. Unity theoretically has race track frameworks you can drop models in. It has an automated road builder which can generate 3D paths.
The licensing & ownership of the game engine is less of a factor over time. The mane showstopper is no-one has really shown a physics system that comes close to Asphalt 9.
The lion kingdom has considered different options for solving the physics problem. The stock godot physics system is crap. Getting useful results from godot would either take too long or require far more engineering than is worth it. If it was easy, everyone would be modeling the Asphalt 9 physics.
What has risen in showers is just modeling physics the way it was done on 8 bit side scrollers. They didn't have any physics. The complete flight path down the track would be hard coded. There would be static acceleration & rotation in the direction of the flight path. The user could turn the rocket with left & right input to add offset to the preprogrammed path, but it would always have a static tendency to accelerate & rotate in the preprogrammed direction.
Speed would use simple acceleration equations & limits. If the user hits nitro, it accelerates to a certain limit. Liftoff accelerates to a certain limit. Hitting a ramp would be a boolean operation rather than a physical simulation of a ramp. When the player hits the end of the preprogrammed flight path, the game is over.
The game still absolutely would require collision detection. Godot's collision detection is just a boolean operation. It can't give the direction of the collision or where in the model the collision happened. All it knows is if the player hit the side of the track, a player hit another player, or a player hit a ramp. Collision reactions would have to be about as limited as they were in 8 bit side scrollers. We can get the vector between 2 players & which side of the track, at least.
If it hits the side of the track, it needs to reverse the velocity perpendicular to the track & constrain the rotation to straight down the track, but the sides aren't parallel to the path. If it hits another player, it knows the velocity vectors of the 2 players so it can use a simple elastic collision between 2 masses. The rotation wouldn't change. The shape of the players would be ignored. RUD's would have the fragments keep going in the player's last velocity vector while expanding, but bounce off of track walls according to simple collision rules. It would have a very 80's appearance.
A big problem with rocket simulators is how slow they are compared to car racers. Elon mentioned in an interview that the starship is going to take off much faster than a normal rocket, so the start could actually be modeled more like a car race while being accurate.
04/09/2020 at 06:33 •
The general idea is the top level physics object is a rigidbody or a staticbody. The rigidbodies move & the staticbodies are stationary. The rigidbody itself doesn't interact with anything but gravity. It has a bunch of collisionshape children which define the shape which interacts with other objects. The collisionshapes are just meshes. The collisionshapes are held in the same relative positions by the rigidbody, like a real solid. The collisionshape geometry determines if the rigidbody rolls over, stands upright, behaves like a ski, a wheel, a leg, or gets stuck.
The rigidbody contains physics parameters which apply to all the collisionshapes, so all the collisionshapes need to have the same mass. Each collisionshape has a shape variable which points to its mesh. The shape member can be created by the shape menu, importing a -col object from blender, or assigning the shape variable in gdscript.
The rigidbody has a center of gravity defined by its pivot point. The CG determines if it's self righting or constantly rolls over. There is no way to set the pivot point like there is in blender. All the collisionshapes & meshes in the rigidbody need to be individually repositioned to change the CG. To simplify matters, a model should have spatial as its top node, a rigidbody directly under that, & a single child node under the rigidbody containing all the visual meshes & collisionshapes. This allows the model to have an arbitrary pivot point for placement in the scene, its CG can be a different pivot point, & its meshes can be another pivot point.
Helas, only spatials can be grouped inside another node. The collisionshapes have to be directly inside the rigidbody & all moved individually. At least you can shift select all the rigidbodies & move them at once.
Godot menus confused the hell out of lions. When a godot menu item says "new...", "new BoxShape" or "new SpatialMaterial", it doesn't create multiple objects or leak memory like new in C++. It just replaces whatever object was already there. The menu title causes the options for the current object to be displayed. The down arrow allows different objects to be created.
Your biggest ally in the war on Godot is the "expand all properties" menu item.
Getting back to rigidbody,
These have to be off until liftoff, to keep players from falling uncontrollably to the launchpads & falling over.
Create one of these to set more properties.
How much the object bounces.
Seems to turn off all bouncing. Now, it just gets stuck when it hits the wall.
A big problem is the global_transform is required for calculating look_at angles & gravity vectors, but it's only available in the _process function. Procedurally generated models have to be created in the _ready function, but anything requiring global_transform has to be done in _process. The distributive property doesn't apply when multiplying transforms by vectors, either.
03/12/2020 at 06:43 •
There is a unique challenge in the distances & altitudes of a BFR flight being much larger than a car. It would be too boring if the player had to wait 8 minutes to reach orbit. There is the timelapse option, but the player still needs rapid maneuverability far beyond a real rocket. The track, obstacles, ramps, & players would have to grow exponentially with altitude to make everything appear just as maneuverable at 300km in timelapse mode as on the ground in realtime mode. It would look pretty awful & not be very realistic to have rapidly expanding models, either.
These days, animals expect realistic flight simulations like Kerbal, Orbiter, & XPlane, but an arcade experience needs to be more like games from 40 years ago. They just had a static space environment & a static ground environment. Players transitioned between the 2 environments at certain times in gameplay.
So the track needs to be scaled way below true orbit insertion dimensions. Displayed values have to be fake values that correspond to a real flight, while the physics system works in drastically scaled down dimensions. Asphalt showed players get bored after 1-2 minutes per game. MECO needs to occur at 45 seconds instead of 2 minutes. The Karman line needs to be 10km instead of 100km. Maximum speed needs to be 500km/h instead of 27000km/h.
The other physics problem is creating fake gravity to make the BFR stay in the track. This is officially done in Godot by creating Area nodes. Each area node has a different gravity vector. Doing this for a track takes over 250 area nodes, though.
The other problem is there's no way to import area nodes from blender like there is for collision nodes by naming them -col. Trying to import a -col shape & change it to an area keeps it as a collision shape in the runtime, regardless of what the editor says. Trying to import a mesh instance & change it to a collision shape keeps it as a mesh instance in the runtime. Finally, there's no way to extract the polygon coordinates from a imported object & procedurally make area nodes from that. The collada exporter exports the polygons out of order, so the polygon sorting would have to be redone in Godot.
The only way to do it is to export a text file with faces from blender & procedurally create area nodes from the text file, basically inventing a whole new file format for blender & godot. The area node with artificial gravity needs to be a heirarchy.
var area = Area.new() add_child(area) var shape = CollisionShape.new() area.add_child(shape) shape.shape = ConvexPolygonShape.new() var vertex_array = PoolVector3Array() shape.shape.set_points(vertex_array)
For just creating cubes of gravity, the area node just needs a ConvexPolygonShape with a set of 8 vertices from blender. No MeshInstance is required except for debugging.
For creating more complicated areas of gravity, the area node needs a ConcavePolygonShape with vertices that form ordered triangles. The lion kingdom never got ConcavePolygonShape to work.
The next major challenge is making the rocket slide down the track & walls instead of getting stuck or bouncing off the surfaces as Godot does. The 1st attempt was a disaster.
A simple rigidbody with CollisionShapes just bounces out of control. 1 idea was defining the rocket as a VehicleBody with 4 VehicleWheels, but the famous vehicle demo
just slides down the horizontal surface & gets stuck on the walls. Adding more wheels has erratic effects.
There is a navmesh demo
where the navmesh correctly makes the player follow the walls of a track, but the player isn't a rigidbody that collides with the walls.
Because of the need for stunts & the artificialness of Asphalt 9, doing physics from scratch is a leading idea. The mane problem is simulating the collisions. It would be easiest to make thousands of area nodes with a precalculated direction of opposing force when the player entered them. That could keep the player out of the areas, but not accurately define the boundary of player movement. Some combination of a navmesh & custom physics might work.
Outside of the artwork, this game is manely the same as any other car racing game. That's why lions thought it would be a simple matter of copying another car racing game. The lack of any car racing games demonstrating the desired physics is a tough spot.
03/04/2020 at 07:02 •
The overlays would go on the bottom for a PC game & the top for a mobile game. The lion kingdom discovered despite the boom in mobile gaming 5 years ago, most gaming is still done on a PC.
This exercise revealed how Godot renders the glyphs in a fixed point size & then scales the output instead of scaling the point size. It looks so awful, all text really needs to be in a separate layer from the graphics, with a manually scaled point size to look good.
An interesting video surfaced of convincing graphics in Kerbal space program. The only environment map is the stars. Godot uses the environment map to draw reflective surfaces, so that wouldn't work on the ground. They use a 2D plane for clouds. The planet is a very large mesh with levels of detail. The atmosphere could be a 2D texture behind the planet. They use particles for some clouds. They use a fog effect, but only on the planet. Godot can't apply fog to just a planet. Lions don't want to port the entire scatterer library.
The lion kingdom has realized without seriously cutting down the graphics, nothing is ever going to happen & the growing amount of investment will be wasted. So it sometimes feels like a toy project with an indefinite finish date, decades in the future & sometimes feels like a disaster.
01/19/2020 at 08:17 •
The journey began with 2 paths for the 2 sides of the track.
An automated script converted the paths into K barriers for the track.
The mane idea is Asphalt 9 had resorted to K barriers to define more detailed tracks inside its existing maps.
So we would define the entire track with K barriers. A procedurally generated collision plane would span between the K barriers. An invisible boundary beyond the barriers would cause the player to go out of bounds while still letting them jump beyond the barriers a certain amount.
Player control would be limited to just sideways & require ramps to jump. The horizontal collision plane, K barriers, & jumps would dictate vertical movement.
The trick was automatically generating the collision planes with the least amount of information. After staring at the model & trying many algorithms, finally figured out the track needs a 3rd line, a direction line to tell the computer what direction the track is pointing. The 2 sides aren't always parallel to the track's direction. With the direction line, it can properly create the right plane between the 2 sides. Without the direction line, there are many possible planes. The direction line also allows the track to do barrel rolls & loops in 3 dimensions.
This was the minimum amount of information required to automatically generate a 3D track with barriers & out of bounds areas. A few sputtering development sessions while commuting yielded
some decent results, at least in model form.
Lions sadly don't like programming games, even though they like the outcome. They're just throwaway content like movies, they don't enhance productivity, but they do make the world a better place. People play through the campaign & throw them away. Making a game stay useful requires constantly expanding the campaign, just like constantly making new movies.
Making the world a better place foremost requires enhancing productivity. It's surprising that peasants in medieval times only occupied 90% of the population, while 99% of today's population would be considered equivalent to peasants since all of our income is eventually consumed by those above us, whether it's through the healthcare system, housing, taxes, inflation, alimony, or our funerals.
We have less leverage than 800 years ago because we're less productive relative to the top 1%. It's much harder to be a google or a facebook than it was to grow food. Creating economically competitive software is ironically not as attainable as we thought it would be.
11/21/2019 at 17:31 •
The hangar was bad, but it was here that the downsizing of expectations became extreme. The mane problem is a 3D flight simulator is just too boring. All the racing games have evolved towards a 2D track in a 3D world. The user input for BFR already got degraded to 2D. Lions are conditioned to want to race in 2D from years of hunting for food on the African plains.
The 1st idea was automating the race course generation from a simple line drawing, the way tuxracer did it.
It didn't have a formal track, but required the player to catch fish in an open world littered with obstacles. The limit was it had a constant elevation grade superimposed on a local elevation defined by the greyscale. Tuxracer looked really good for its time, but flying required more 3D flexibility.
Even an indie game like GRIP looks better than tuxracer. That led to needing a full sized 3D model.
A good race course needs:
track collision borders
environment maps for sky & space
The current gold standard for clouds is XPlane. No example in Godot
comes close & you would need to be a dedicated mathematician to invent
that from scratch.
The only godot example of 3D clouds was the terrible
There was an excellent cloud generator for Unity
While it may seem like Godot is all paw coding of shaders, Unity also requires a lot of paw coding of shaders. They depend on very slow 3D textures & ray tracing.
The XPlane clouds might actually be still photos, in which case lions might be better off just photographing clouds & stuffing them in 2D rectangles.
Tuxracer just used a 2D texture for trees & it looked pretty good.
Stars may similarly be good enough as 2D textures
A 1st attempt using arrows to define a 2D track was really boring. Devising the route has devolved towards just copying other racing games.
The track collision shape can similarly be based on the track line drawing.
There's sadly no tool for making environment maps. Godot examples all just copy the existing ones from hdrihaven.com. Making something appear to transition from ground to space requires custom environment maps.
The lion kingdom still goes back & forth between the tuxracer design & full 3D modeling. The track has ended up just 2D with a constant elevation grade because the arrows are 2D. Real spaceships don't fly 3D paths either. They all fly in a 2D plane. The trick is the 2D plane is vertical & the starting line needs to be vertical. Any maneuvering in a real rocket is just in altitude.
06/15/2019 at 04:48 •
The mane mac bug is they tried to implement acceleration based navigation but failed. The acceleration part either doesn't refresh completely or switches to rotation partway through the animation. This makes navigation crosstalk between rotation & translation & studder.
The result is navigating is nearly impossible on a mac. On Linux, the acceleration is implemented properly, so the crosstalk & studdering doesn't happen. Ideally, there would be no acceleration on any platform.
On the mac, antialiasing & reflections are much faster than Linux. Godot drops key release events on Linux, making keyboard input during a slow framerate impossible.
Reflections from other nodes are horrendous on any platform. It looks worse than Doom 1. The only way to get remotely acceptable reflections is to make an environment map of the hangar. Environment map reflections in godot are acceptable. No-one has ever made an equirectangular projection from a godot scene. They only did it in Blender. The real BFR may not be shiny at all.
05/28/2019 at 00:01 •
Like polygon editing, there's no textual documentation on the subject & only random bits of information on video. It wasn't possible at all to get anywhere with Blender before gootube took off in 2010. Many functions are only accessible by the keyboard. What you want is a workflow, but no videos were giving that.
The decision was made to just watch videos & write as many notes as possible.
In the UV/Image editor:
Selection of UVs works the same as edit mode. The selection mode uses different icons which change depending on the "keep UV & edit mode selection in sync" button.
"keep UV & edit mode selection in sync" has to be enabled & face selection has to be enabled to do anything useful. Selecting edges or vertices causes it to ignore seams & treat the faces as linked. Only selecting faces allows UV islands to be moved independently. This is a huge bug.
c circle selection
b box selection
UVs -> mark seam - make the smart UV mapper not keep faces next to each other. Marked seams are shown as red in edit mode. The seams create UV islands.
ctrl-l select linked faces in the texture
g,r,s - translate, rotate, scale
e - extrude
x,y,z - typed after the g,r,s,e to restrict movement of g,r,s,e to X, Y, Z axis
numerical entry: typed last after g,r,s,e. depends on whether it's in translate, rotate, or scale mode
0 - for translating, make UV's equal on the axis movement is restricted to
- for scaling, scale it to the value entered
- for rotation, set rotation to the angle
There's no numerical entry textbox for UV's like there is for mesh editing. The textbox which appears when transforming UV's just affects the mesh.
UVs -> pack islands - line up the UVs with the edges of the texture to maximize the space usage. Only aligns 2 edges since it doesn't alter the aspect ratio.
UVs -> show/hide faces -> shift-h hide unselected
UVs -> export UV layout - generates a PNG with the UV coordinates outlined
There's no way to dial in any coordinates. Your only option for precise alignment is snapping to a grid.
There's no magic way to tile textures. Just extend the face beyond the edges of the texture. It's a nightmare for every large faces.
Eventually a workflow emerged, which involved defining seams to create UV islands, unwrapping each island separately onto its own area of a texture, exporting the UV layout, & drawing in Gimp. The drawing ended up relying on the path tool, what Disney hottie called the "pen tool", the gradient tool, & the selection tools.
The mane drawing workflow is to create a line using the path tool & stroke it in a certain brush or make a selection with the path tool to restrict the gradient & fill operations to a certain area.
The path tool & gradient tool are the mane differences from the lion kingdom's last involvement in 2D drawing, 30 years ago. 30 years ago, computers had no greyscale so there was no gradient tool. PC paint had only a 3 point curve tool, which lions used extensively. The modern path tool is the evolution of that curve tool.
Early paint programs were all designed to be pixel accurate. A mane problem with Gimp is it's not designed to be pixel accurate. The xored marching ants & brush outlines from vintage programs are now 3D outlines & no brush indication. There's no longer a grid showing the location of every pixel when zoomed in. Having a hardware cursor seems to have made programmers not want to provide a software cursor of any kind.
Between PC Paint & modern tools, there was an object oriented drawing craze involving Adobe Illustrator. The beauty of object oriented drawing was being able to adjust any operation later without redrawing everything. When 24 bit color & pressure sensitive tablets came along, it might have been too computationally intensive even today to make all those nuanced operations non destructive.
After 2 months, that was the best a lion could do. There's always room for more details, like tracks in the floor for the rocket stands, tool boxes. Navigation is not as easy as the smaller models in Asphalt. Translating around the walls of the hangar works. The camera needs a smarter algorithm than always pointing towards the center. The stainless steel reflects the environment map instead of the hangar.
Reflecting the polygons in godot requires adding a worldenvironment, enabling ss reflections. It's extremely slow & looks terrible. Asphalt 8 manages to do it fast.
05/12/2019 at 08:14 •
It occurred to the lion kingdom that the race course should be a 2D route through the upper level winds. The winds would have to be rendered like land masses or clouds. The space section would have to be a route through a dense sea of stars. The only way anything can be playable is if it's very artistic instead of accurate. It definitely has to be 2D to work on a tablet.
It occurred to the lion kingdom that with Musk now caught up in John Green books, the name BFR is free & clear, so the thing should be called BFR.
Working on the game makes lions want to play Asphalt 9 & reminds them of commuting, since most of the work is done on a train & the game is based on Asphalt 9. This results in wasted days playing Asphalt 9 to avoid being reminded of commuting.
The godot editor is so bad, a key requirement is a way to freeze the game & view from arbitrary cameras. The camera previewer in the editor is non functional & most of the models are synthesized in the game.
The garage scene in Asphalt XTreme uses textures heavily to simulate polygons. The shadows aren't even drawn very accurately, but it still works.
Thus, when it came time for the hangar scene in BFR, lions were woefully unprepared to make the custom textures. It's ironic that animals who did much paper drawing & struggled transitioning to 3D models now have a hard time with the 2D drawing required to make textures.
To someone who was alive over 40 years ago, modern paint programs are better for editing photos & terrible for drawing 2D. Compare this to millenials who can't imagine drawing anything on paper & make big bucks drawing 2D on computers. There is a millenial trophy wife showing that professional art is drawn electronically, but not showing any tutorials.
The computer interface definitely limits it to a certain style. Surprising how much TV art is 2D & computer art has evolved from 3D to 2D as they've learned how to make better interfaces.