@track modders: have a look at this: http://forum.mx-bikes.com/index.php?topic=888.msg14944#msg14944 (http://forum.mx-bikes.com/index.php?topic=888.msg14944#msg14944)
I'm not sure if you're (all) already aware, but you should :)
Current Aragon for example has mountains far away that are not in the background model: this means that they are rendered only if they are below the drawdistance which, by default, is 1Km (max value in game). So they appear and disappear as you goL: very bad looking. A workaround is to manually increase the drawdistance in the profile.ini, but it's very annoying as as soon as you enter the GPB settings page/menu it will overwrite it (like the fov thing).
Hi,
Thank you.
Is it not possible to create a little batch who insert the distance value desired each time the game is launch?
So I'm presuming the "background" model can be a true 3D to scale mesh of distant hills/mountains and not just panoramic images on a flat plane? And they will show still show up in the default draw distance no matter what true scale distance those hills/mountains are from the riders viewpoint?
That would be great! ;D 8)
Hawk.
Quote from: janaucarre on April 13, 2016, 11:13:42 AM
Hi,
Thank you.
Is it not possible to create a little batch who insert the distance value desired each time the game is launch?
Yes but as soon as you enter the settings menu you're screwed. Also it's a very ugly solution and it's inefficient (to have a huge drawdistance).
Distant objects should just be in the background model (3d model, the skydome is something else): it's whatthe background model is made for.
@Hawk: yes, my understanding is that the background model if a full blown 3d model that is drawn independently of the drawdistance.
The "flat" skydome is something else and the two (of course) can (and should) be used together.
I tried this with Mugello and the hills got a bit better but the far ones bad even at 2000000 and then the whole screen was flickering!!!
If this happens it is better as you say to do it through modeling. Thought I would say about the flickering.
DD
The background model is briefly mentioned in the various sections here: http://docs.piboso.com/wiki/index.php/Track_Tools (http://docs.piboso.com/wiki/index.php/Track_Tools)
(TrackEd, Track creation rules)
Quote from: HornetMaX on April 13, 2016, 11:35:36 AM
The background model is briefly mentioned in the various sections here: http://docs.piboso.com/wiki/index.php/Track_Tools (http://docs.piboso.com/wiki/index.php/Track_Tools)
(TrackEd, Track creation rules)
Yes I've see that before, but there is no explanation of why a background model is of any benefit as far as draw distances are concerned, so having seen the post from the MXB site link above, it's the first time I can see a benefit of creating the background.edf model. This is were Piboso needs to think that we are not telepathic and automatically know what he knows... He needs to explain every element of what does what and why when he publishes tools and the like..... It tends to be a common failing when the programmers write the user manuals, they assume too much; in consequence modding work is not up to the standard which GPB is capable because we don't know about these things. ::)
@DD: I seem to remember, if I'm not mistaken, that in one of Pibs daily dev entries he says he has now sorted the distant texture flickering issue? ;)
Hawk.
PS: But I'm sure the background models I've seen from the background.edf file are not actual 3D, they are images on a flat plane.... I hope this is not a limitation, that would be disappointing after hearing about all this. :(
@Hawk: you could chime-in int he MXB forum dicussion. Or create a topic here. I do think we don't have enough info on that: always going by trial and error gets quickly annoying.
But I leave that discussion to you guys, you've much more experience in tracks modding than me (well, I have zero, so ...).
Excellent. Thanks for passing on the info.
Can see this layer getting the ass kicked out of it. :D Could also be used for building lods too as long as the low poly lod version was a little smaller than the main model so it could be encased and hidden as the main appeared.
I still think your initial suggestion of upping the draw distance has merit though. When you turn onto the back straight at Aragon it's more than 1km to the far end of the circuit so even if all the surrounding landscape was visible there'd still be an 'hole' where the track and fences were growing in front of you. A cheeky wee lod model could go some way to hiding it but I'd rather take my chances and double the max draw distance.
Anyhow, great news Max, cheers again. ;)
I'd tend to agree that it should anyway be possible in-game to manipulate the draw distance to more than 1Km. It's a tiny fix (same thing applies for FOV limitations, for example).
I've used background.edf a few times. It works well for being able to interchange scenery without changing the entire skydome, but no matter what your 3d model for background looks like, it is still projected in skydome fashion i.e flat.
I noticed a bug with background.edf where it's constantly in shadow. So in my last track I copied my background model into my skydome model and it looks identical to having them separate, things seem to be rendered at exactly the same distance.
I definitely think the point still stands about long distance scenery, as for me background.edf offers no sense of scale unless we're talking about mountains that are intended to be part of the skydome anyway.
Thx TFC !
Ach, I'm really really starting to think that we should have a common forum for all PiBoSo's sims for modding questions / technical support.
Quote from: TheFatController on April 13, 2016, 01:16:22 PM
I've used background.edf a few times. It works well for being able to interchange scenery without changing the entire skydome, but no matter what your 3d model for background looks like, it is still projected in skydome fashion i.e flat.
I noticed a bug with background.edf where it's constantly in shadow. So in my last track I copied my background model into my skydome model and it looks identical to having them separate, things seem to be rendered at exactly the same distance.
I definitely think the point still stands about long distance scenery, as for me background.edf offers no sense of scale unless we're talking about mountains that are intended to be part of the skydome anyway.
Trouble with flat background images is that they don't alter in perspective as you move around the scene... They are terrible! It would be much better to have a true 3D mesh scene for the background especially with a mountainous background scene.
In a simulation it is the immersion factor we are looking for and not old tricks like the flat panoramic background images. :)
@TFC: You have actually exported a true 3D mesh scene and it coverts that into a flat image? That doesn't sound right to me? I'm not saying your wrong, but it just seems a lot of programming work to have to do that from a 3D mesh scene when if it's a flat image Piboso requires there are much easier ways to produce a flat background image than to programme a routine to convert a 3d scene into a flat image on a flat plane or skydome.
If it will only project a flat image then that is disappointing and not really worth bothering with as it doesn't provide any true perspective at all.
I'm not sure there is true LOD processing..... The draw distance seems to be the only optimisation going on for drawing objects but that is not true LOD processing?
Hawk.
Come on trackmaster Hawk, get your hands dirty and do a test :)
Quote from: HornetMaX on April 13, 2016, 02:11:15 PM
Come on trackmaster Hawk, get your hands dirty and do a test :)
Haha! ;D
I'll do you a deal Max.... You do the live replay plugin we want for live-streaming events and I'll do this test. ;D
And that's taking into account I'm already doing an IOM feasibility test right now, working on Project "X" with Matty, part of an active bikeMOD team, as well as converting a track and creating another from scratch. Oh! And also the Yamaha YZR 0W60 project that I still have yet to find time to finish.......
So this sounds a good deal to me. What do you say Max..... Deal? ;D ;D
Hawk
Quote from: Hawk on April 13, 2016, 02:37:12 PM
Quote from: HornetMaX on April 13, 2016, 02:11:15 PM
Come on trackmaster Hawk, get your hands dirty and do a test :)
Haha! ;D
I'll do you a deal Max.... You do the live replay plugin we want for live-streaming events and I'll do this test. ;D
I'll do something like showing the current standings and gaps on an overlay, that was already in my plans (it would help me a bit if PiBoSo took the time to briefly explain how to create our own fonts with sprgen, but I can do without).
I won't do anything around camera control: that's something GPB must provide (well, it already provides it, probably just needs some improvement).
BTW, what would you need in terms of camera control that is not already there ?
Sorry guys, I'm not sure of the correct terminology to use here :).. Let me try!
If you create a skydome, which by definition is a dome / 3d object (although I'm aware it can be a cube or other shape) in game it acts as though it's origin is the viewport at all times - As if you never get closer or further away from it.. Almost like you're wearing an umbrella hat..
(http://netmag.hu/wp-content/uploads/2014/09/bruce-almighty.jpg)
The same is true for background.edf. It's essentially the same thing as a skydome, except it's rendered before the skydome I guess?.. Definitely in front of it.
So to conclude, you never get further away or closer to it, it's origin is the viewport. Although I'm not sure it's being converted to an image, it definitely doesn't offer any perspective.
As an example in MX-Bikes, let's say you ride on the stock 'Practice Track': The sky is 'clearsky.edf' and the trees you see on the horizon are 'background.edf'.
And MaX, I agree with having one place for all this! I come here quite often (and KRP) to search for things I can't find the answer to in the Wiki or on MXB ;)
Cheers for clearing things up.
...and the tip about dropping backdrop rings in with skydomes to avoid shadows. ;)
Quote from: Hawk on April 13, 2016, 02:05:45 PMI'm not sure there is true LOD processing..... The draw distance seems to be the only optimisation going on for drawing objects but that is not true LOD processing?
For a real-deal lod setup you have two draw distances and three models. In the first bubble the high poly model is rendered, between that and the second bubble it's the next model down then outside that is the last(very simple) model. The game's switching models on the fly as the bubbles move around with you.
That'd be nice but just a single model layer unaffected by draw distance would do to be getting on with. It'd sort out the landscape woes and give some scope to fake-lod things to avoid them springing into view. :)
Hmmm.... Interesting.... I see what your saying there TFC..... So it could be useful to do a test with a full blown 3D background scene? I say this because if it transforms and renders points for a single plane image as the background(as you say a skydome is a 3D object in virtual space), then there is a chance that it could also transform and render a full 3D background scene in virtual space? ;D
I'll do a test and we'll see what happens. ;D
Thanks TFC! ;) 8)
Hawk.
Quote from: HornetMaX on April 13, 2016, 02:42:36 PM
Quote from: Hawk on April 13, 2016, 02:37:12 PM
Quote from: HornetMaX on April 13, 2016, 02:11:15 PM
Come on trackmaster Hawk, get your hands dirty and do a test :)
Haha! ;D
I'll do you a deal Max.... You do the live replay plugin we want for live-streaming events and I'll do this test. ;D
I'll do something like showing the current standings and gaps on an overlay, that was already in my plans (it would help me a bit if PiBoSo took the time to briefly explain how to create our own fonts with sprgen, but I can do without).
I won't do anything around camera control: that's something GPB must provide (well, it already provides it, probably just needs some improvement).
BTW, what would you need in terms of camera control that is not already there ?
Camera Controls: The problem with the current camera controls on Live Replay during live streaming is that the producer/commentator has to open the drop-down menu to select a rider from the list - this is very intrusive during a live stream as you can see it happening on screen. It would be so much better to be able to click on one of the rider widgets to change camera that you plan to have on screen that show a riders position during the race.
Also having your dynamic track map on the replay screen for the producer/commentator to be able to see were the action is happening during the race too would be great too, otherwise the producer/commentator cannot see were the action is happening and has to keep flicking through the different riders to see what is happening(very frustrating to see this during live streaming). In other words the Commentator would be operating blind without your dynamic map to reference the action during the race.
Either that or some kind of unobtrusive character field were the producer could enter the number of the rider(the commentator could see from your track map) and that would take you to the camera for that rider? :)
But definitely being able to just click on the rider position widgets that you plan to create would be the best and most usable option for the live stream producer to change cameras. ;D
Maybe DD would have some other ideas too that would be of great help on live replay for live stream events? :)
Hawk.
No problem, interested to see what you come up with Hawk, be sure to post! :)
Quote from: Hawk on April 13, 2016, 03:58:44 PM
Camera Controls: The problem with the current camera controls on Live Replay during live streaming is that the producer/commentator has to open the drop-down menu to select a rider from the list - this is very intrusive during a live stream as you can see it happening on screen. It would be so much better to be able to click on one of the rider widgets to change camera that you plan to have on screen that show a riders position during the race.
I disagree: to be able to click on a dot on the track map you'll have to have a mouse pointer showing on the screen. How's that in terms of intrusiveness ?
The proper way to do that is via keyboard shortcuts (e.g. ctrl+ 0..9 = riders in pos 1..10, alt + 0..9 = riders in pos 11..20, ctrl+alt+0..9 = riders in pos 21..30 etc).
Plus shortcuts for prev/next rider, usual tv-style camera sets etc).
And all that is something GPB can (and should) do without any plugin.
Quote from: Hawk on April 13, 2016, 03:58:44 PM
Also having your dynamic track map on the replay screen for the producer/commentator to be able to see were the action is happening during the race too would be great too, otherwise the producer/commentator cannot see were the action is happening and has to keep flicking through the different riders to see what is happening(very frustrating to see this during live streaming). In other words the Commentator would be operating blind without your dynamic map to reference the action during the race.
Having the map (and some other widgets) during live replay mode is something I can and will do (that too was already in my todo list). No ETA however.
Quote from: HornetMaX on April 13, 2016, 07:23:05 PM
Quote from: Hawk on April 13, 2016, 03:58:44 PM
Camera Controls: The problem with the current camera controls on Live Replay during live streaming is that the producer/commentator has to open the drop-down menu to select a rider from the list - this is very intrusive during a live stream as you can see it happening on screen. It would be so much better to be able to click on one of the rider widgets to change camera that you plan to have on screen that show a riders position during the race.
I disagree: to be able to click on a dot on the track map you'll have to have a mouse pointer showing on the screen. How's that in terms of intrusiveness ?
The proper way to do that is via keyboard shortcuts (e.g. ctrl+ 0..9 = riders in pos 1..10, alt + 0..9 = riders in pos 11..20, ctrl+alt+0..9 = riders in pos 21..30 etc).
Plus shortcuts for prev/next rider, usual tv-style camera sets etc).
And all that is something GPB can (and should) do without any plugin.
Quote from: Hawk on April 13, 2016, 03:58:44 PM
Also having your dynamic track map on the replay screen for the producer/commentator to be able to see were the action is happening during the race too would be great too, otherwise the producer/commentator cannot see were the action is happening and has to keep flicking through the different riders to see what is happening(very frustrating to see this during live streaming). In other words the Commentator would be operating blind without your dynamic map to reference the action during the race.
Having the map (and some other widgets) during live replay mode is something I can and will do (that too was already in my todo list). No ETA however.
Do it the way you feel is best Max.... As long as it does the job well that's the main thing. ;D ;) 8)
I can't wait to see it! (ETA pending) ;D
Hawk.
Quote from: Hawk on April 13, 2016, 08:49:09 PM
Do it the way you feel is best Max.... As long as it does the job well that's the main thing. ;D ;) 8)
For the cam part, you'll have to see this with the boss :)
Quote from: Hawk on April 13, 2016, 08:49:09 PM
I can't wait to see it! (ETA pending) ;D
I have to update MaxSCL: poor Warlock not only has the toughest job out there (creating decent bike sounds with minimal tools) but has also been waiting for this forever :)
Quote from: HornetMaX on April 13, 2016, 09:10:14 PM
Quote from: Hawk on April 13, 2016, 08:49:09 PM
Do it the way you feel is best Max.... As long as it does the job well that's the main thing. ;D ;) 8)
For the cam part, you'll have to see this with the boss :)
Quote from: Hawk on April 13, 2016, 08:49:09 PM
I can't wait to see it! (ETA pending) ;D
I have to update MaxSCL: poor Warlock not only has the toughest job out there (creating decent bike sounds with minimal tools) but has also been waiting for this forever :)
Okay no worries Max, whenever your ready mate. ;) 8)
Hawk.