da timetable57 » 11 gen 2012, 23:52
Hello and Happy new year to all.
I hear what you say (and agree with your wish list and items still to do). However, there's still only me coding and I have a fulltime job and other commitments, so "spare time" to develop Rail3D is sometimes hard to find. Three of the four points raised are not particularly difficult to code and won't take long to do once I get to them, however before I can even think about that I need to finish the 106 code sufficient to release it, and I can't do an interim 105.xx release at the moment because the code changes for 106 have meant some fundamental changes to the internals (rendering code). More below. The fourth item (more sounds) doesn't actually need me ;-) There is a LOT that can be done by the user community, particularly in sourcing sound files. The scripting system has quite a lot of support for sound, so if sound is an issue you are concerned about: get on with it! Find the sound files, test them out using the sound features built in so far, extend the features using scripting etc (and I'll add them to the code in due course). So over to you - let's see some development from you ;-) As to the 106 code, it has a significant change to the rendering model, in particular with much more use of multiple threads to handle the work of generating and rendering the display. This is intended to give a faster and smoother display, but (as any one with experience of multi-thread coding will know) introduces its own problems in handling thread synchronisation. At the same time there is also new code in #106 to render a much enhanced track model. See http://rail3dwiki.markhodson.nl/index.php?n=V106.3DTrackModel for comparison screenshots. (this feature can be turned off) BTW, Just noticed the wiki has been badly defaced - if anyone can spare some time to repair the damage (use revert) it would be appreciated. OR Mark - is there a global revert option? So, having been busy with other things for a while, I'm starting to get back to Rail3D. Last night I spent a lot of time looking at Benchmarking the program to get a handle on what it is doing. This trace shows the FPS for a ten minute run in three versions of the program: Train starts in area of simple plain line, runs into a major station with a lot of track and junctions (middle of trace) and out other side to plain line again. The blue trace is the frame rate of the current #105 build, the red trace is the #106 code without the new 3D track turned on and the green #106 with the extra 3d track mode turned on. All of which is OK, the comparison of blue and green is the most interesting, which shows that (generally) the extra detail in the track is not causing significant detriment to the frame rate. However, the problem is the smoothness. The changes to #106 were intended to make the rendering much smoother. compare these traces of the time to render each frame: The blue trace is again #105, and note the big spikes - these are where the simulation pauses and is not smooth, the code changes were intended to eliminate these. But look at the #106 (green) trace. It's actually spiking bigger (ie longer, less smooth). So I need to look at this and work out why and what is going on. This will be the focus of my coding time for the next few days. BTW, I wouldn't want you to think #106 is a step backwards - the above is a severe test case - in most "normal" layouts #106 is MUCH smoother and runs at MUCH better frame rates than #105 #106 is actually stable and has other nice features in it (such as tail lamps), so I have considered making it available as a limited (pre-beta) release to group members. But at the moment I'd really like to address the above problems and give you some code that is working well all the way. and by the way, Rail3D is older than MSTS and RW ;-) |
da Alpiblu » 12 gen 2012, 0:48
da RobitailleFan » 12 gen 2012, 1:40
Ciao e Buon anno a tutti.
Ho letto ciò che è stato scritto (e sono d'accordo con la vostra lista dei desideri e gli elementi ancora da fare). Tuttavia, sono ancora solo io a scrivere il codice e ho un lavoro a tempo pieno e altri impegni, quindi "tempo libero" per sviluppare Rail3D a volte è difficile da trovare. Tre dei quattro punti sollevati non sono particolarmente difficili da codificare e non richiedono molto tempo una volta che arrivati al punto, ma prima devo anche pensare che ho bisogno di finire la versione 106 del codice in modo sufficiente a rilasciarlo, e non posso fare un rilascio intermedio 105.xx in questo momento perché le modifiche al codice per la versione 106 hanno fatto alcuni cambiamenti fondamentali per internals (non saprei come tradurre correttamente, non conosco la terminologia del codice macchina) (codice di rendering). Vedi più sotto. Il quarto punto (più suoni) in realtà non ha bisogno di me ;-) c'è molto che può essere fatto dalla comunità degli utenti, in particolare nel sourcing dei file audio. Il sistema di scripting ha un bel po 'di supporto per il suono, quindi se il suono vi sembra un problema non preoccupatevi: andare avanti! Trovate i file audio, testateli usando le funzionalità del suono integrate finora, estendere le funzionalità utilizzando lo scripting ecc (e io li aggiungerò al codice in tempo utile). Quindi, forza - vediamo un po 'di sviluppo da parte vostra ;-) Per quanto riguarda la versione 106, che ha un significativo cambiamento del modello di rendering, in particolare con un uso maggiore di più thread per gestire il lavoro di generare e rendere il display. Questo è destinato a dare una visualizzazione più rapida e fluida, ma (come uno con esperienza di multi-thread di codifica saprà) presenta i suoi problemi nella gestione di sincronizzazione dei thread. Allo stesso tempo c'è anche nella nuova versione N ° 106 la capacità di renderizzare un modello in maniera migliore. Vedi http://rail3dwiki.markhodson.nl/index.php?n=V106.3DTrackModel per gli screenshots di confronto. (Questa funzione può essere disattivata) A proposito, ho appena notato che la Wiki è stata gravemente danneggiata - se qualcuno può risparmiare del tempo per riparare il danno (usando il "revert") sarebbe apprezzato. O Mark - c'è una opzione globale di revert?? Così, dopo essere stato impegnato con altre cose per un po', sto iniziando a tornare a Rail3D. Ieri sera ho passato un sacco di tempo a guardare il programma di benchmarking per ottenere un ritorno su ciò che sta facendo. Questa traccia mostra l'FPS per dieci minuti a correre in tre versioni del programma: [b]Immagine:[/b] 32,21 KB Il treno si muove isu una linea pianeggiante a binario semplice, attraversa una stazione importante con un sacco di binari e raccordi (al centro delle tracce) e esce dall'altro lato su una linea di pianura di nuovo. La traccia blu è il frame rate della corrente versione 105, la traccia rossa è la versione del codice 106 senza la nuova opzione binari 3D e la verde la versione 106 con la modalità supplementare binario 3d attivato. Va tutto bene, il confronto tra i frame rate blu e verde è la parte più interessante, che dimostra che (generalmente) il dettaglio in più dei binari non è causa di abbassamento significativo per il frame rate. Tuttavia, il problema è la scorrevolezza. Le modifiche alla versione 106 sono stati destinate a fare il rendering molto più fluido. Confrontate queste tracce del tempo speso per il rendering di ogni fotogramma: [b]Immagine:[/b] 23,88 KB La traccia blu è di nuovo la versione 105, notate i picchi principali - questi sono dove la simulazione si impunta e non è fluida, le modifiche al codice avevano lo scopo di eliminare questo. Ma guardate la traccia verde del codice 106. In realtà i picchi sono più grande (cioè più tempo, meno fluida). Quindi ho bisogno di guardare questo e capire perché e cosa sta succedendo. Questo sarà il focus del mio tempo per la codifica per i prossimi giorni. Non vorrei che voi pensaste che la versione 106 è un passo indietro - quanto sopra è un banco di prova severo - nella maggior parte dei "normali" layout la versione 106 è molto più fluida e gira a frame rate MOLTO meglio della 105 La versione 106 è effettivamente stabile e ha altre caratteristiche interessanti in essa (come le lampade di coda), quindi non ho considerato che la renderò disponibile in edizione limitata (pre-beta) ai membri del gruppo. Ma al momento mi piacerebbe davvero per affrontare i problemi di cui sopra e vi darò un codice che funziona bene fino in fondo. e tra l'altro, Rail3D è più vecchio di MSTS e RW ;-) |
da Alpiblu » 12 gen 2012, 10:50
da RobitailleFan » 12 gen 2012, 11:21
... [b]quindi[/b] |
da timetable57 » 12 gen 2012, 12:02
da RobitailleFan » 12 gen 2012, 12:10
timetable57 ha scritto:
.... Vittorio ricevi anche tu le e-mail dallo yahoo group? (I grafici non ero riuscito a metterli) |
da Alpiblu » 12 gen 2012, 18:58
RobitailleFan ha scritto:
Lo ho appena riletto, e devo dire la verità che ho fatto una caterva di errori , per fortuna quasi tutti di ortografia a parte un "NON" in più che (ovviamente) stravolge il significato. La frase giusta è:
Scusate un povero di spirito che tenta di parlare in una lingua non sua ... |
da strawberryfield » 12 gen 2012, 19:02
Messaggio di timetable57
Vi trasmetto integralmente la risposta di Mark alle nostre richieste di sviluppo per Rail3D. Direi molto incoraggianti.
A parte il punto 4 pare che avremo il resto....con un po' di pazienza |
da timetable57 » 19 mar 2012, 23:04
Well, the short (and standard) answer is "when it's ready".
The longer answer is "probably very soon". I've made a lot of progress with some of the outstanding issues in the last week or so, and should be sending out a new build to the alpha testers in the next 24 hours. Assuming they don't find any issues with it (ie if it works on their machines) it *might* be ready for a wider release. There is at least one new feature that is not working - but this is not an essential and it would be possible to disable this in order to get a new release out. I'm aware that there hasn't been a code release for a long time, and there are a lot of things waiting on this new release, so I'll probably publish the code once all the essentials are ready and not wait for all the "nice to have" features to be complete. When we do get to that point, I am considering a different release process to the usual one. Usually when there is a new public build, it goes on the updater and anyone can have it. Because this new release includes some major revisions to the rendering code and the current group of alpha testers is fairly small, I may make the new version available to the members of this group by download in the first instance instead of on the general public updater. This means that you will be able to opt into trying the new version before its general release, and it will mean a bit more work than just running the updater to get it going. So at this point, I'm in the process of putting together a new build for the alpha testers which should go to them today or tomorrow. If that is found to be good, I then want to spend some time looking at the benchmark layouts to measure the performance of the new code against the old versions and will make a decision based on the results of those tests about a wider release. Realistically, this is not likely to be before the weekend at the earliest. MRG |
da strawberryfield » 19 mar 2012, 23:14
da timetable57 » 19 mar 2012, 23:38
da Giancarlo » 20 mar 2012, 23:15