I will test the shifting sounds as soon as possible.
Simplifying the code seems always like a good idea top me.
I would consider the weedwhacker sound only as an option but not as the default since to me it doesn't sound like any car I have ever heared at all.
I still feel the sound quality of the samples is more relevant than the amount of samples. Therefore, I still prefer "Tim" and "Paula". Maybe you can use equipment from a local free radio station if something like that exists in your area. But the codriver commands where never something I was attached to since I most of the time use Trigger Rally only with very low sound.
I fear I don't have good ideas how to improve the textures for the cars. Mainly because it is very tricky to get the mapping correct. Many cool things I wanted to do didn't work because the projection is very odd. I guess we would need to have better meshes in order to do something sensible with it. ... And that brings me to the old problem: I think the most fun would be to have more different and better cars. We probably wouldn't even need to be so conservative with the amount of vertices any more. Or at least should use them better. In the past the evo even had transparent lights and the actual texture of the head lights was a little behind this transparent surface.
I explicitly wanted to have the unlocking of new stuff like cars in order to gain something that enables players to make progress. If I can't progress in any way my motivation to start the same game over and over again is very low. I suspect I am not the only one feeling this way. So having to many options right away wouldn't improve my experience but making it rather dull.
I am all for different skid sounds but I don't even own a license to drive a car and most people I know are not very interested in helping me out recording such sounds for a free game. But I guess it is just something that isn't high enough on my priority list. I can imagine it shouldn't be all to hard to record with inexpensive equipment. Maybe even using a normal cell phone that you hold out of the window close to the rear wheel would be sufficient if you can do some maneuvers on a training ground.
Last edit: Onsemeliot 2019-03-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would consider the weedwhacker sound only as an option but not as the default since to me it doesn't sound like any car I have ever heared at all.
The alternative would be to rip true engine sounds from YouTube videos. This of course requires getting permission from the original uploader. Back then I've created a sample sound from a video as proof that it's a practical idea: someone with audio editing experience can make such a rip even better. The trick is to loop a constant high rev. Too bad Iwan is absent.
I still feel the sound quality of the samples is more relevant than the amount of samples.
I am not denying that the "ab" recording quality is low, however the larger number of samples has the purpose of making the voice sound less robotic. Or did you mean "amount of samples" as "number of codriver voices"? In that case I agree there's no need to add a new voice, just improve the existing ones.
I fear I don't have good ideas how to improve the textures for the cars.
Iwan provided us with sample fake ads for the cars. I do not recall the reason why you didn't like using them, maybe it's time to reconsider?
I did try it some days ago but even if I don't think I overlooked something when importin the new sounds I actually didn't notice any difference. The new release should contain everything needed, right? Maybe I didn't pay close enough attention before I made the update. At least nothing seems to be broken ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When the gears are changed there is a random chanceshiftup.wav or shitdown.wav will be played. The problem is the engine sound is loud while the shift sounds are quiet so it's hard to hear them. Perhaps they should be normalized?
EDIT: looked at the code again and it's not a randomized event, yet for some reason sometimes it's completely inaudible.
Last edit: Andrei 2019-04-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I committed [r947] that fixes issues with the camera code and the Fox car. When we made the Fox RWD, its center of mass was moved back for a better handling. This broke in the first place the HOOD camera mode since it ended up drawing a section of the car too. In the second place it broke the car choosing menu since the Fox cars spinned around the new center of mass and it was bad looking. I fixed these issues in this way: the HOOD and BUMPER camera modes do not anymore even try to render the car, fixing the first issue (and maybe improving performance?). there is a new field 'render_pos' in the .vehicle file, completely optional. It is added only for the two Fox cars and define around which position the car should spin in the menu.
Problem #2 was circumverted in [r951]. I couldn't see why the engine changes gears without updating the direction (gear up or gear down?) so I just forced a third sound effect for "unknown gear shift".
We were discussing the addition of physical objects with collision cages in the past. I think it could improve the game a lot if we where able to use things like rocks, bridges, walls, tunnels and tree trunks. I can't tell how difficult the implementation would be but it could extend the variation in our maps considerably.
Maybe we would be able to create a basic archive of simple objects that could be used as an extendable library similar to vegetation sprites, road signs and vehicles. Objects could be positioned in our map files using coordinates and scale values. If we had that we could even create buildings.
The only issue I see here is that we probably would want to have some kind of shadow since big objects would look very odd without it – especially when creating things like tunnels.
The easier first step might be the head and tail lights on our vehicles. But if that would introduce real dynamic light and shadows this would make the game probably very different and much more ressource hungy.
But even without any kind of shadow I think collision objects could improve the game considerably.
Of course if we wanted to create improved 3-dimensional trees we would need an advanced way of placing sprites with leaves onto these objects since it would look odd if leaves could only grow out of the stem. It would be possible to create sprites that at least partially counter that effect by having leaves just in specific areas and using some different sprites for each tree in order to not end up with very obviously repeated patterns but at the present we would only be able to use standing surfaces that are rotated around the stem. For sure there are better ways to do something like this without wasting limited resources on old hardware.
Andrei and Emanuele: would you be interested in working on such options?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Onsemeliot I would be happy to contribute to this option, it's a very complex and articulated work thought. So surely I can help but I do not know if I can handle it all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe we shouldn't try to do everything at once. It could be less demanding to make little steps.
Do you think you can introduce any collidable object no matter how basic? For example just a block of stone in the form of a rectangular prism? Even such blocks would allow to create tree stems and walls if it was possible to place them with coordinates.
I only fear the needed third dimension in placing them could collide with the way heightmaps are generated. Surely the heightmap and its scaling would need to be finished before placing any objects since otherwise we would end up with burried or flying objects.
We could theoretically avoid the need for a third dimension by deriving the objects vertical position value on the map the same way it is done for straffic signs.
Of course this would even strenghen the issue we have already with "unrooted" trees on steep slopes since the base of a rectangular prism is not narrower than anything further up. As with trees we would be only able to solve the issue by placing every instance somewhat under the ground. How much deeper the object should begin depends very much on how uneven or steep the terrain is and how wide the object base itself is. (See the attached image for clarification.)
I hope my thoughts are not confusing or discuraging you.
Today I treid the Fox KitKar again. And I think in the state it comes with the installation isn't usable. It is just a car no sensible person would use because you can only increase speed when not steering at all. And even then it is incredibly hard to keep on track. Then I switched from RWD to FWD and it instantly was fun to drive again.
I really like the idea of having a RWD car in the game but if it behaves the way it is now it's better to not have it. (I am sorry because originally I clainmed to be fine with it. But I was wrong.)
Even having a considerably weaker Fox but with FWD makes much more sense to me than havin a RWD car that just doesn't work in the game in any sensible way. Because then a challenge could be to drive the tracks in the best time possible with the weaker car. But driving a crazy car that can't be sensibly steered doesn't make any sense to me.
(I will soon be able to finish the new event I have been working on for a while now.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'd enjoy tunnels and bridges the most. It could be implemented using multiple height fields. Z-order would decide which one should be treated as the ground map.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, I dont get how this should work since at the moment every height map needs to be exactly the size of the other map images. This leads to the effect that surfaces are either above or below the current height map on the whole map. They could overlap but this would mean that the vehicles get stuck between two surfaces if those two surfaces get closer to each other or even touch. As long as we dont have a way of creating holes in the height map I fear this won't work.
And as mentioned already tunnels without real light sources (and therefore shadows) do not sound like much fun to me. It would be rather odd entering a tunnel that is exactly as bright as everything else around it.
Last edit: Onsemeliot 2019-09-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
it took me some time to precise my "invention".
First of all - I've discovered that color map may be of size being multiplication of others (height, terrain, widgets density - AKA foliage map). So, I'm using 4K color map while others are 1K. It works.
Back to tunnels AND bridges. Here is my solution:
1) use base height map and some height overlays. It my, or shoud be PNG 16bit graymaps using alpha channel, or alternatively 24bit PNG's, but GB bits may be used to map height (this ensures perfectly smooth roads) and R channel to code "holes".
2) game engine checks Z-order - if the car is between base map and below 1st overlay it checks if corresponding bits are transparent or Red. If so, car is outside the "tunnel". If not - it is inside . Tunnel itself may be textured according to relevant overlay color map. If overlay is below the car and none is above), this means, that car is on the bridge.
3) This localize whole program change in procedures evaluating contact of whels with terrain. Of course, now maps should be kept in some sort of array.
4) Additional computing cost would depend on the number of overlays - more overlays implies more computing power ofc. Thus in .layer file switch for ancient computers might be added to ignore overlays.
I think this will work or at least be interesting ;)
Another suggestion for version 3.7 may be to add a random position for the road sign marker (and stiffen "road signs"), but only on demand - because real road signs should always be in place. The Roadsign tag can be used for including of various parts of the scene: banners, animals or just eastern eggs. E.g. with "road signs" you can set a vertical (or even inclined wall useful in some cases, such as the construction of tribuns) HD quality.
BTW: On my Win10 TR still does not works...
Best regards,
Janusz
PS: New racing track/event is on the way
This sounds like a clear improvement and it probably doesn't need much code. Would it possible to set the higher resolution of the colour map in the map files as an option – so that we don't lose backwards-compatibility?
Concerning bridges I fear having just a plane without any thickness might look very odd and not very realistic. If you drive under a bridge and look up you would see Bridge.png as the texture, right? And the bridge would always look like made out of paper since the plane obviously lacks any volume.
And how would tunnels look from the inside? Would it look just like the whole hill where it is going through is hollow? So not actually a tunnel through a hill but just like driving under a planket wehre every feature of the surface is seen from below? Or do we need to use a third layer for the tunnel itself that is placed above the normal height map but below the additional heightmap that creates the hill? (To illustrate what I mean I attached the conceptual image: tunnel-concept.png.)
Using this technique we could actually get rid of the problem of planes without volume also since the second height map wouldn't need any transparancies ever. The third plane would only cut out the second and therefore allow us to create bridges like in my bridge-concept.png image.
I looked into your code and saw that there is some kind of light/shadow definitions also but I don't understand it fully.
Hi!
Concept with 4K color map (4096x4096 pixels not 32 bit) and 1K (ie. 1024x1024) height map actually works quite well and doesn't require any new code. Only drawback I've found is probably subtle shift of the texture.
Tunnels:
yes, it would require additional internal layer and I think that it may work your way without alpha channel. More simple solution should be selected. BTW, currently there is no way to render flat vertical planes. This would be new feature.
Lights in tunnel:
I've attached POVRay example just for reference. POVRay code requires light sources but TR don't. This is because in TR pixels shines by themselves (like in your track "Dark Forest"). So the solution is the same as with water and underwater planes.
Bridges:
In order to have realistic look they should have some thickness, but for "just driving over" not. Let look at my Suzuka F1 track. I had to make long jump feature to implement fake road bridge over track. Thick bridges are, in fact the same case as hills with tunnel inside. The only difference is road placement.
BR,
Janusz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
4K color map ... actually works quite well and doesn't require any new code.
Cool. But still a little adaptation to the code is necessary. Or did I just miss that possibility so far?
More simple solution should be selected.
Yes, I agree. But I am uncertain what this means in practice.
currently there is no way to render flat vertical planes.
Ok, I thought you have solved this already because this is what you rely on heavily in your images.
So the solution is the same as with water and underwater planes.
Sorry, I don't understand how water planes are related to lightening.
It would be great to have actual light sources (and shadows). This would allow us to introduce head- and tail lights also. But it might be to much to render for old systems that come without hardware acceleration for graphics.
In order to have realistic look they should have some thickness, but for "just driving over" not.
It may be true that just the function wouldn't need a volume but it would look so bad that if it is up to me I would introduce the feature only if we also create the possibility to give objects a volume. As you clearly have shown in your images the change you proposed would allow us also to create walls. This is something I wanted to have a long time. It would be great to create a road along a deep slope that could have a low wall. This seems to be rather common in reality.
Thick bridges are, in fact the same case as hills with tunnel inside.
Yes, this is what I realised aslo. Therefore I don't really get why you wanted to use alpha chanels. To me bridges and tunnels wouldn't be satisfying without thickness. To me it actually isn't very important to have true vertical planes. The possibility to have very steep slopes would be sufficient in my view.
On a side note: In some of my newer maps I used map files in larger resolutions in order to be able to have not only a more detailed colour map but also in order to make smoother roads. I needed them to be very smooth because I uced racing tarmac which does not work well with bumps. So, only increasing the resolution of the color map isn't always sufficient. "Terminal Velosity" is the most extreme example of this. In order to allow fluent rendering on my system I needed to use heavy fog (or in this case darkness) because renering more of the landscape (aka a wider view) would have made the race to a horrible slide show instead of a smooth ride. "Smoothie" is an other less extreme example.
Ok, I thought you have solved this already because this is what you rely on heavily in your images.
I've added fake vertical planes just by using specially crafted PNG bitmps with alpha channel as roadsigns (eg. moon and cityscape on Bahrajn F1 circuit). They are not tough and one may easily go through. Stiff vertical planes are required for placing fences, barriers and buildings on and around the track.
Yes, I agree. But I am uncertain what this means in practice.
Less code lines to add/modify.
Sorry, I don't understand how water planes are related to lightening.
Implementation of ligtening in tunnels may be the same as for underawter/night sky.
Real lights are very greedy on computing power but we want to keep TR playable on older computers (I succesfuly ran it on computer from 2004, on Ubuntu until it stopped getting up on 18.04 :( ) however.
Therefore I don't really get why you wanted to use alpha chanels.
It just allows for easy placing of chunks of terrain here and there, so you don't need to cope with full sized height map.
So, only increasing the resolution of the color map isn't always sufficient.
I use higher resolution of colormap just for better look. Vertical resolution of the height map is important for smoothness of the surface. Using 8bit resolution makes bumps, especially visible on almost flat slopes. So height map MUST use whole 8bit range what allows for less than 1.0 scale tag, eg. on my new Paul Riccard track I'm testing verticalscale=".05". Ultimate solution is emploing 16bit grayscale bitmaps, but there is a problem with editing software. New Inkscape 1beta1 may export bitmaps in this format and GIMP 2.10.14 handles them out of box, but TR 6.6 doesn't use it properly. Making vertical resolution of height bitmaps 16bit (or more) would be a big improvement.
Best regards,
J.
Last edit: Onsemeliot 2019-11-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Real lights are very greedy on computing power but we want to keep TR playable on older computers.
Indeed. We want to avoid that. But I guess it would be possible in theory for example to add just lights without creating shadows at the same time. This could for example improve graphics by introducing breack lights with would be nice too. :)
I am not certain if it would be truly easier to deal with alpha chanels since the positioned features would need to fit to the mormal height map anyway. It seems to me just creating a black additional height map only adding brighter spots where you need them to stand out above the normal height map wouldn't really be harder to do and seem to be more predictable to me since it would always result in a closed surface – no matter how steep or flat features on it are.
We indeed talked about 16bit greyscale height maps in the past. But Andrei intoduced the blurfilter option which helped a lot for creating maps with greater height variation.
Last edit: Onsemeliot 2019-11-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But Andrei intoduced the blurfilter option which helped a lot for creating maps with greater height variation.
Of course many thanks to Andrei for that, but this is more workaround than solution. There are some drawbacks as well. For example blur matrix isn't normalized by default which influences vertical scaling and shape of out of road parts is unnecesarily affected too.
This could for example improve graphics by introducing breack lights with would be nice too.
Sure! It may be sufficient to have alternate textures for the given car. Moreover pixels just "before" the car along vector parallel to the symmetry axis of the car may be rendered brighter. But this still requires several additional processor ticks.
Last edit: Onsemeliot 2020-01-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Onsemeliot could you look into the Upshift/downshift sounds patch and confirm that credits and licenses used would be OK for Trigger Rally?
I've tried it out and it sounds good enough, though the effects could be made a bit louder.
Other than this I'd like to simplify the code, if possible. I believe I've made this list once before but here goes:
I could think of a couple of other things which should be relatively easy to do for those interested?
Anything else?
I will test the shifting sounds as soon as possible.
Simplifying the code seems always like a good idea top me.
I would consider the weedwhacker sound only as an option but not as the default since to me it doesn't sound like any car I have ever heared at all.
I still feel the sound quality of the samples is more relevant than the amount of samples. Therefore, I still prefer "Tim" and "Paula". Maybe you can use equipment from a local free radio station if something like that exists in your area. But the codriver commands where never something I was attached to since I most of the time use Trigger Rally only with very low sound.
I fear I don't have good ideas how to improve the textures for the cars. Mainly because it is very tricky to get the mapping correct. Many cool things I wanted to do didn't work because the projection is very odd. I guess we would need to have better meshes in order to do something sensible with it. ... And that brings me to the old problem: I think the most fun would be to have more different and better cars. We probably wouldn't even need to be so conservative with the amount of vertices any more. Or at least should use them better. In the past the evo even had transparent lights and the actual texture of the head lights was a little behind this transparent surface.
I explicitly wanted to have the unlocking of new stuff like cars in order to gain something that enables players to make progress. If I can't progress in any way my motivation to start the same game over and over again is very low. I suspect I am not the only one feeling this way. So having to many options right away wouldn't improve my experience but making it rather dull.
I am all for different skid sounds but I don't even own a license to drive a car and most people I know are not very interested in helping me out recording such sounds for a free game. But I guess it is just something that isn't high enough on my priority list. I can imagine it shouldn't be all to hard to record with inexpensive equipment. Maybe even using a normal cell phone that you hold out of the window close to the rear wheel would be sufficient if you can do some maneuvers on a training ground.
Last edit: Onsemeliot 2019-03-29
The Upshift/downshift patch requires the following data changes:
The two new .WAV files are released under CC0:
Files: shiftup.wav shiftdown.wav Copyright: 2019, Bruno Kleinert <fuddl@debian.org> Comment: Edited bang_05.ogg, © 2019 rubberduck Downloaded from https://opengameart.org/content/25-cc0-bang-firework-sfx License: CC0/Public DomainThe alternative would be to rip true engine sounds from YouTube videos. This of course requires getting permission from the original uploader. Back then I've created a sample sound from a video as proof that it's a practical idea: someone with audio editing experience can make such a rip even better. The trick is to loop a constant high rev. Too bad Iwan is absent.
https://sourceforge.net/p/trigger-rally/discussion/527953/thread/60c28120c2/45d8/attachment/engine-1.wav
I am not denying that the "ab" recording quality is low, however the larger number of samples has the purpose of making the voice sound less robotic. Or did you mean "amount of samples" as "number of codriver voices"? In that case I agree there's no need to add a new voice, just improve the existing ones.
Iwan provided us with sample fake ads for the cars. I do not recall the reason why you didn't like using them, maybe it's time to reconsider?
https://sourceforge.net/p/trigger-rally/discussion/527953/thread/9f68e48b/?page=1&limit=25#16ae
https://sourceforge.net/p/trigger-rally/discussion/527953/thread/9f68e48b/16ae/attachment/fakebrands2.7z
I decided to apply Bruno's patch as-is, in [r946].
Related
Commit: [r946]
I did try it some days ago but even if I don't think I overlooked something when importin the new sounds I actually didn't notice any difference. The new release should contain everything needed, right? Maybe I didn't pay close enough attention before I made the update. At least nothing seems to be broken ...
When the gears are changed
there is a random chanceshiftup.wav or shitdown.wav will be played. The problem is the engine sound is loud while the shift sounds are quiet so it's hard to hear them. Perhaps they should be normalized?EDIT: looked at the code again and it's not a randomized event, yet for some reason sometimes it's completely inaudible.
Last edit: Andrei 2019-04-10
I can confirm this. I actually think I never hear the upshifting but often the downshiftig.
I committed [r947] that fixes issues with the camera code and the Fox car. When we made the Fox RWD, its center of mass was moved back for a better handling. This broke in the first place the HOOD camera mode since it ended up drawing a section of the car too. In the second place it broke the car choosing menu since the Fox cars spinned around the new center of mass and it was bad looking. I fixed these issues in this way:
the HOOD and BUMPER camera modes do not anymore even try to render the car, fixing the first issue (and maybe improving performance?).
there is a new field 'render_pos' in the .vehicle file, completely optional. It is added only for the two Fox cars and define around which position the car should spin in the menu.
Related
Commit: [r947]
Cool, thank you for keeping at it and providing a solution. I will test it as soon as possible.
There are actually 3 Fox cars. I suspect you didn't unlock the "super" cars yet.
The Super Fox car is
FWD4WD, so it was never been affected by the issue. The only two car to be RWD are the Fox WRC and the Fox Kitcatedit: I meant 4WD (your impressions were right, sorry :c)
Last edit: Emanuele Sorce 2019-04-12
Ah, of course, you are right. But interesting, when I think about it I had the impression that all super cars are 4WD.
@Onsemeliot:
This is a combination of two problems:
Problem #1 is fixed by editing your trigger-rally-0.6.7.config file and changing audio volumes:
Problem #2 was circumverted in [r951]. I couldn't see why the engine changes gears without updating the direction (gear up or gear down?) so I just forced a third sound effect for "unknown gear shift".
Related
Commit: [r951]
We were discussing the addition of physical objects with collision cages in the past. I think it could improve the game a lot if we where able to use things like rocks, bridges, walls, tunnels and tree trunks. I can't tell how difficult the implementation would be but it could extend the variation in our maps considerably.
Maybe we would be able to create a basic archive of simple objects that could be used as an extendable library similar to vegetation sprites, road signs and vehicles. Objects could be positioned in our map files using coordinates and scale values. If we had that we could even create buildings.
The only issue I see here is that we probably would want to have some kind of shadow since big objects would look very odd without it – especially when creating things like tunnels.
The easier first step might be the head and tail lights on our vehicles. But if that would introduce real dynamic light and shadows this would make the game probably very different and much more ressource hungy.
But even without any kind of shadow I think collision objects could improve the game considerably.
Of course if we wanted to create improved 3-dimensional trees we would need an advanced way of placing sprites with leaves onto these objects since it would look odd if leaves could only grow out of the stem. It would be possible to create sprites that at least partially counter that effect by having leaves just in specific areas and using some different sprites for each tree in order to not end up with very obviously repeated patterns but at the present we would only be able to use standing surfaces that are rotated around the stem. For sure there are better ways to do something like this without wasting limited resources on old hardware.
Andrei and Emanuele: would you be interested in working on such options?
@Onsemeliot I would be happy to contribute to this option, it's a very complex and articulated work thought. So surely I can help but I do not know if I can handle it all.
Maybe we shouldn't try to do everything at once. It could be less demanding to make little steps.
Do you think you can introduce any collidable object no matter how basic? For example just a block of stone in the form of a rectangular prism? Even such blocks would allow to create tree stems and walls if it was possible to place them with coordinates.
I only fear the needed third dimension in placing them could collide with the way heightmaps are generated. Surely the heightmap and its scaling would need to be finished before placing any objects since otherwise we would end up with burried or flying objects.
We could theoretically avoid the need for a third dimension by deriving the objects vertical position value on the map the same way it is done for straffic signs.
Of course this would even strenghen the issue we have already with "unrooted" trees on steep slopes since the base of a rectangular prism is not narrower than anything further up. As with trees we would be only able to solve the issue by placing every instance somewhat under the ground. How much deeper the object should begin depends very much on how uneven or steep the terrain is and how wide the object base itself is. (See the attached image for clarification.)
I hope my thoughts are not confusing or discuraging you.
Today I treid the Fox KitKar again. And I think in the state it comes with the installation isn't usable. It is just a car no sensible person would use because you can only increase speed when not steering at all. And even then it is incredibly hard to keep on track. Then I switched from RWD to FWD and it instantly was fun to drive again.
I really like the idea of having a RWD car in the game but if it behaves the way it is now it's better to not have it. (I am sorry because originally I clainmed to be fine with it. But I was wrong.)
Even having a considerably weaker Fox but with FWD makes much more sense to me than havin a RWD car that just doesn't work in the game in any sensible way. Because then a challenge could be to drive the tracks in the best time possible with the weaker car. But driving a crazy car that can't be sensibly steered doesn't make any sense to me.
(I will soon be able to finish the new event I have been working on for a while now.)
Hi,
I'd enjoy tunnels and bridges the most. It could be implemented using multiple height fields. Z-order would decide which one should be treated as the ground map.
Hi janusz, thank you for contributing your idea.
Unfortunately, I dont get how this should work since at the moment every height map needs to be exactly the size of the other map images. This leads to the effect that surfaces are either above or below the current height map on the whole map. They could overlap but this would mean that the vehicles get stuck between two surfaces if those two surfaces get closer to each other or even touch. As long as we dont have a way of creating holes in the height map I fear this won't work.
And as mentioned already tunnels without real light sources (and therefore shadows) do not sound like much fun to me. It would be rather odd entering a tunnel that is exactly as bright as everything else around it.
Last edit: Onsemeliot 2019-09-18
Hi,
it took me some time to precise my "invention".
First of all - I've discovered that color map may be of size being multiplication of others (height, terrain, widgets density - AKA foliage map). So, I'm using 4K color map while others are 1K. It works.
Back to tunnels AND bridges. Here is my solution:
1) use base height map and some height overlays. It my, or shoud be PNG 16bit graymaps using alpha channel, or alternatively 24bit PNG's, but GB bits may be used to map height (this ensures perfectly smooth roads) and R channel to code "holes".
2) game engine checks Z-order - if the car is between base map and below 1st overlay it checks if corresponding bits are transparent or Red. If so, car is outside the "tunnel". If not - it is inside . Tunnel itself may be textured according to relevant overlay color map. If overlay is below the car and none is above), this means, that car is on the bridge.
3) This localize whole program change in procedures evaluating contact of whels with terrain. Of course, now maps should be kept in some sort of array.
4) Additional computing cost would depend on the number of overlays - more overlays implies more computing power ofc. Thus in .layer file switch for ancient computers might be added to ignore overlays.
I think this will work or at least be interesting ;)
Another suggestion for version 3.7 may be to add a random position for the road sign marker (and stiffen "road signs"), but only on demand - because real road signs should always be in place. The Roadsign tag can be used for including of various parts of the scene: banners, animals or just eastern eggs. E.g. with "road signs" you can set a vertical (or even inclined wall useful in some cases, such as the construction of tribuns) HD quality.
BTW: On my Win10 TR still does not works...
Best regards,
Janusz
PS: New racing track/event is on the way
Thank you very much, Janusz.
This sounds like a clear improvement and it probably doesn't need much code. Would it possible to set the higher resolution of the colour map in the map files as an option – so that we don't lose backwards-compatibility?
Concerning bridges I fear having just a plane without any thickness might look very odd and not very realistic. If you drive under a bridge and look up you would see Bridge.png as the texture, right? And the bridge would always look like made out of paper since the plane obviously lacks any volume.
And how would tunnels look from the inside? Would it look just like the whole hill where it is going through is hollow? So not actually a tunnel through a hill but just like driving under a planket wehre every feature of the surface is seen from below? Or do we need to use a third layer for the tunnel itself that is placed above the normal height map but below the additional heightmap that creates the hill? (To illustrate what I mean I attached the conceptual image: tunnel-concept.png.)
Using this technique we could actually get rid of the problem of planes without volume also since the second height map wouldn't need any transparancies ever. The third plane would only cut out the second and therefore allow us to create bridges like in my bridge-concept.png image.
I looked into your code and saw that there is some kind of light/shadow definitions also but I don't understand it fully.
Last edit: Onsemeliot 2019-11-11
Hi!
Concept with 4K color map (4096x4096 pixels not 32 bit) and 1K (ie. 1024x1024) height map actually works quite well and doesn't require any new code. Only drawback I've found is probably subtle shift of the texture.
Tunnels:
yes, it would require additional internal layer and I think that it may work your way without alpha channel. More simple solution should be selected. BTW, currently there is no way to render flat vertical planes. This would be new feature.
Lights in tunnel:
I've attached POVRay example just for reference. POVRay code requires light sources but TR don't. This is because in TR pixels shines by themselves (like in your track "Dark Forest"). So the solution is the same as with water and underwater planes.
Bridges:
In order to have realistic look they should have some thickness, but for "just driving over" not. Let look at my Suzuka F1 track. I had to make long jump feature to implement fake road bridge over track. Thick bridges are, in fact the same case as hills with tunnel inside. The only difference is road placement.
BR,
Janusz
Cool. But still a little adaptation to the code is necessary. Or did I just miss that possibility so far?
Yes, I agree. But I am uncertain what this means in practice.
Ok, I thought you have solved this already because this is what you rely on heavily in your images.
Sorry, I don't understand how water planes are related to lightening.
It would be great to have actual light sources (and shadows). This would allow us to introduce head- and tail lights also. But it might be to much to render for old systems that come without hardware acceleration for graphics.
It may be true that just the function wouldn't need a volume but it would look so bad that if it is up to me I would introduce the feature only if we also create the possibility to give objects a volume. As you clearly have shown in your images the change you proposed would allow us also to create walls. This is something I wanted to have a long time. It would be great to create a road along a deep slope that could have a low wall. This seems to be rather common in reality.
Yes, this is what I realised aslo. Therefore I don't really get why you wanted to use alpha chanels. To me bridges and tunnels wouldn't be satisfying without thickness. To me it actually isn't very important to have true vertical planes. The possibility to have very steep slopes would be sufficient in my view.
On a side note: In some of my newer maps I used map files in larger resolutions in order to be able to have not only a more detailed colour map but also in order to make smoother roads. I needed them to be very smooth because I uced racing tarmac which does not work well with bumps. So, only increasing the resolution of the color map isn't always sufficient. "Terminal Velosity" is the most extreme example of this. In order to allow fluent rendering on my system I needed to use heavy fog (or in this case darkness) because renering more of the landscape (aka a wider view) would have made the race to a horrible slide show instead of a smooth ride. "Smoothie" is an other less extreme example.
Last edit: Onsemeliot 2019-11-12
I've added fake vertical planes just by using specially crafted PNG bitmps with alpha channel as roadsigns (eg. moon and cityscape on Bahrajn F1 circuit). They are not tough and one may easily go through. Stiff vertical planes are required for placing fences, barriers and buildings on and around the track.
Less code lines to add/modify.
Implementation of ligtening in tunnels may be the same as for underawter/night sky.
Real lights are very greedy on computing power but we want to keep TR playable on older computers (I succesfuly ran it on computer from 2004, on Ubuntu until it stopped getting up on 18.04 :( ) however.
It just allows for easy placing of chunks of terrain here and there, so you don't need to cope with full sized height map.
I use higher resolution of colormap just for better look. Vertical resolution of the height map is important for smoothness of the surface. Using 8bit resolution makes bumps, especially visible on almost flat slopes. So height map MUST use whole 8bit range what allows for less than 1.0 scale tag, eg. on my new Paul Riccard track I'm testing verticalscale=".05". Ultimate solution is emploing 16bit grayscale bitmaps, but there is a problem with editing software. New Inkscape 1beta1 may export bitmaps in this format and GIMP 2.10.14 handles them out of box, but TR 6.6 doesn't use it properly. Making vertical resolution of height bitmaps 16bit (or more) would be a big improvement.
Best regards,
J.
Last edit: Onsemeliot 2019-11-12
Indeed. We want to avoid that. But I guess it would be possible in theory for example to add just lights without creating shadows at the same time. This could for example improve graphics by introducing breack lights with would be nice too. :)
I am not certain if it would be truly easier to deal with alpha chanels since the positioned features would need to fit to the mormal height map anyway. It seems to me just creating a black additional height map only adding brighter spots where you need them to stand out above the normal height map wouldn't really be harder to do and seem to be more predictable to me since it would always result in a closed surface – no matter how steep or flat features on it are.
We indeed talked about 16bit greyscale height maps in the past. But Andrei intoduced the blurfilter option which helped a lot for creating maps with greater height variation.
Last edit: Onsemeliot 2019-11-12
Of course many thanks to Andrei for that, but this is more workaround than solution. There are some drawbacks as well. For example blur matrix isn't normalized by default which influences vertical scaling and shape of out of road parts is unnecesarily affected too.
Sure! It may be sufficient to have alternate textures for the given car. Moreover pixels just "before" the car along vector parallel to the symmetry axis of the car may be rendered brighter. But this still requires several additional processor ticks.
Last edit: Onsemeliot 2020-01-11