Alexander Knoll
NEVER GIVE UP!!
hi,
small update, new link in first post.
small update, new link in first post.
Released SchottenRing_67, GTL Conversion...
- Thread starter Alexander Knoll
- Start date
Alexander Knoll
NEVER GIVE UP!!
urgh..i take a look...sry...
EDIT:strange...i tested it and it works well...please try it again...
EDIT:strange...i tested it and it works well...please try it again...
Alex,
Tried the update, not a lot of change was found, FPS still yhe same, MB sign on side of building still flickers as does the yellow bush that tries to be in the same place as a green bush. Also there was no default ai, the original one still works but has a spot that takes a car off the track into something solid.
Otherwise looks ok.
Tried the update, not a lot of change was found, FPS still yhe same, MB sign on side of building still flickers as does the yellow bush that tries to be in the same place as a green bush. Also there was no default ai, the original one still works but has a spot that takes a car off the track into something solid.
Otherwise looks ok.
Alexander Knoll
NEVER GIVE UP!!
Hello Bob, thx for the feedback.
Yes i know it's not muche done...but for the mom i have not the time to make big steps...
Will see what i can do in my next holidays...
Alex
Yes i know it's not muche done...but for the mom i have not the time to make big steps...
Will see what i can do in my next holidays...
Alex
Alexander Knoll
NEVER GIVE UP!!
Hello Bob,
FPS always not changed...
MB sign Fixed...
yellow bush Fixed...
...try the new default ai ...this time it's recorded with the Toyota Cressida JZX30 from FSR....
@ all
...new Link in first post...
Alexander Knoll
NEVER GIVE UP!!
THX Bob,
ok, if no one is willing to help me with that atlas texture thing i think this can be a final...maybe i change some shaders, if i get a idea over the weekend and look for this LOD thing to get up a little the fps...
Alex
ok, if no one is willing to help me with that atlas texture thing i think this can be a final...maybe i change some shaders, if i get a idea over the weekend and look for this LOD thing to get up a little the fps...
Alex
Alex: The atlas texture method is not - IMNSHO - such a great thing. Sure, it might
load faster, but as I like to alter textures I like them to be single images, for the most.
Don't worry about it
But I would, if I were me, and I am, alter some of the original
images so they have more "texture", they look very flat and dull in some parts, like
the grass and such. The Race07 version looks more lively, mostly due to shaders,
but you can improve even the original with better textures and shaders.
Just my 2c.. and it's not worth a p..
load faster, but as I like to alter textures I like them to be single images, for the most.
Don't worry about it
But I would, if I were me, and I am, alter some of the originalimages so they have more "texture", they look very flat and dull in some parts, like
the grass and such. The Race07 version looks more lively, mostly due to shaders,
but you can improve even the original with better textures and shaders.
Just my 2c.. and it's not worth a p..
Alexander Knoll
NEVER GIVE UP!!
THX Luke...
...i already tried to alter the grass...but with no realy good looking luck...will see...
...i already tried to alter the grass...but with no realy good looking luck...will see...
Using a texture atlas doesn't mean it loads quicker. The total VRAM is the same. What changes is that each time the GPU gets to a new shader (or DOF even with the same shader) it has to process data to make the change to the new shader.
Since this type of render engine expects people to optimise their shader count down (since it's not hard to do, it's just an intensive task without tools that do it automagically for you like bigger developers probably use), if you don't optimise, then you are basically over-loading your GPU with a pointless task every single frame. Literally swapping state for rendering possibly the same shader many times on copies of the same object which just so happen to be different dof.
Or rendering 10 things with the same shader settings, just a different texture for each house down a street or something.
There are 1053 textures on Schottenring, but I bet you could get that down to just 50 big textures.
You could then combine hundreds of DOF objects into ones with a shared material/shader. Then you could cut it up depending on distance (ie, 250m long blocks, or maybe 500m). Then you could put smaller items into a second set of DOF with a 250m LOD cut-off so they are not even drawn when they are far away as they get so small or insignificant.
Please note I'm not beating any one up over this. It IS hard to take a BIG track like this and optimise it. It takes a lot of time and a fair degree of planning and testing to get LOD values right etc.
I did say I would help and I will do. It might be a year from now but I will help optimise it.
First though I want to make a tutorial converting the Hockenheim Ring from GTR2 (freely available for download still iirc), and include the optimisation part. Then hopefully people can see how fast it runs with minimal batches, AND see how to think about the process of optimising it.
That will come nearer Christmas as I'm busy with other stuff right now.
As I said earlier though, this track should run about 5 x faster with appropriate optimisations... if not more if you really dig in and tweak LOD's for every item at every point on the track, splitting certain items up and LOD'ing even more etc...
Real commercial games like PGR2 (from what I heard from a developer at the time) had people driving round again and again just marking out items with an LOD bias so in the final 'compile' of the track geometry/shaders to the game everything ran at the desired FPS.
We don't have those tools, but we can get close by just using sensible processes at first. Maybe we won't get that last 10% of FPS like they did by cutting every last thing up perfectly and LOD'ing it to the last metre of perfection when setting values, but then again we are doing this for fun
Dave
Since this type of render engine expects people to optimise their shader count down (since it's not hard to do, it's just an intensive task without tools that do it automagically for you like bigger developers probably use), if you don't optimise, then you are basically over-loading your GPU with a pointless task every single frame. Literally swapping state for rendering possibly the same shader many times on copies of the same object which just so happen to be different dof.
Or rendering 10 things with the same shader settings, just a different texture for each house down a street or something.
There are 1053 textures on Schottenring, but I bet you could get that down to just 50 big textures.
You could then combine hundreds of DOF objects into ones with a shared material/shader. Then you could cut it up depending on distance (ie, 250m long blocks, or maybe 500m). Then you could put smaller items into a second set of DOF with a 250m LOD cut-off so they are not even drawn when they are far away as they get so small or insignificant.
Please note I'm not beating any one up over this. It IS hard to take a BIG track like this and optimise it. It takes a lot of time and a fair degree of planning and testing to get LOD values right etc.
I did say I would help and I will do. It might be a year from now but I will help optimise it.
First though I want to make a tutorial converting the Hockenheim Ring from GTR2 (freely available for download still iirc), and include the optimisation part. Then hopefully people can see how fast it runs with minimal batches, AND see how to think about the process of optimising it.
That will come nearer Christmas as I'm busy with other stuff right now.
As I said earlier though, this track should run about 5 x faster with appropriate optimisations... if not more if you really dig in and tweak LOD's for every item at every point on the track, splitting certain items up and LOD'ing even more etc...
Real commercial games like PGR2 (from what I heard from a developer at the time) had people driving round again and again just marking out items with an LOD bias so in the final 'compile' of the track geometry/shaders to the game everything ran at the desired FPS.
We don't have those tools, but we can get close by just using sensible processes at first. Maybe we won't get that last 10% of FPS like they did by cutting every last thing up perfectly and LOD'ing it to the last metre of perfection when setting values, but then again we are doing this for fun
Dave
I.e. it loads the texture. Maybe we just understand the terminology differently.
But, you are way too technical for most users and I did not want Alex to be
discouraged since he did not know how to make a texture atlas. He converted
a track and used what the track had, there is no need to push him, or anyone
else, into doing something that the track originally did not require. It really
does not matter if another method is better, the point is, Alex did a good
job and should be credited for that and not scolded for not doing it a different
way. Please.. give them a chance FCOL.
Each object in scene uses a texture. Each texture uses a shader.
Thus every scene geometry item has a shader.
A million trees using the same texture can thus be one shader, or one million shaders, even if the texture is common!
Every time a shader is called to be rendered, it is batched. The CPU is involved in that task too. It gets all the stuff ready, from geometry, to shader to textures, and passes it all on to the GPU to render. That is a costly process and one of the biggest costs to overall rendering speed.
Think of it like a trip to go shopping. Ideally we want to go shopping once and do as much as we can in that trip, because it's inefficient to go back for each item.
However, items do eventually get split between the bakery and butchers and green grocers, so there is no avoiding making several trips at some stage.
In the shopping example, it's better to go shopping three times, than once for each item.
So having things that can all go together means we can 'buy' them all together... and that means less trips.
So even if we atlas all our trees up into one big atlas, but still use thousands of DOF for the trees, there will be thousands of batches processed and even though they are small, it is still the same kind of CPU cost as if it were one big batch with thousands of trees in it.
The travelling to the shop analogy works because the batch method is designed to do BIG jobs less frequently than lots of small apparently easy jobs quickly.
The travelling is the most time consuming bit, and that is state/texture changes for the GPU as the CPU sends the new batch to be rendered!
So in practice, atlas textures to save on shader count. Then optimise geometry so you don't see too much at once (no point batching trees/buildings you can't see as it takes up GPU memory to store the data).
But at the same time you don't want to draw things that can all be seen at once in more than one batch if you can help it. Ie, a street of houses that can all be seen at once may as well be always done in one batch.
Obviously this does all take time and practice to achieve, so as I said I'm not beating any one up over not doing it.
It'll take some time to work out good ways to do it, especially on already made content you are trying to convert!
I just want to make it clear that there IS a big benefit to be found by atlas/batch optimisation. As said, ideally we might be looking at about 50-75 batches for this track and about 100fps vs 25fps on my machine!
It is REALLY well worth persevering over playing with making an atlas, even if you just start with the trees (easy usually) and then combine ALL the tree geometry for the whole course... then chop it up into blocks about 400m long, then add an LOD range of about 800m.
Suddenly you will be rendering about 2-4 batches tops for ALL the trees, rather than maybe 30-40.
That might be 10fps right there, and in practice because trees are so basic in UVW mapping it might only take you 2hrs to do it!
Trees are easy I will admit, but as you start to understand the principle it will make sense and it may even become a fun task to optimise and work out the best ways to do stuff.
Batch optimisation is the only way to get good performance unfortunately... but it's great because it's relatively easy... it's just a task that needs to be done.
I'm busy right now in real life working a Sunday haha, but I will help with making these tracks faster running and help show how to think about batching optimisations for Racer a bit more!
No slur on anyone's work or skills here, just purely an optimisation task that does need to be done and trudged through to get the very best FPS
Dave
Thus every scene geometry item has a shader.
A million trees using the same texture can thus be one shader, or one million shaders, even if the texture is common!
Every time a shader is called to be rendered, it is batched. The CPU is involved in that task too. It gets all the stuff ready, from geometry, to shader to textures, and passes it all on to the GPU to render. That is a costly process and one of the biggest costs to overall rendering speed.
Think of it like a trip to go shopping. Ideally we want to go shopping once and do as much as we can in that trip, because it's inefficient to go back for each item.
However, items do eventually get split between the bakery and butchers and green grocers, so there is no avoiding making several trips at some stage.
In the shopping example, it's better to go shopping three times, than once for each item.
So having things that can all go together means we can 'buy' them all together... and that means less trips.
So even if we atlas all our trees up into one big atlas, but still use thousands of DOF for the trees, there will be thousands of batches processed and even though they are small, it is still the same kind of CPU cost as if it were one big batch with thousands of trees in it.
The travelling to the shop analogy works because the batch method is designed to do BIG jobs less frequently than lots of small apparently easy jobs quickly.
The travelling is the most time consuming bit, and that is state/texture changes for the GPU as the CPU sends the new batch to be rendered!
So in practice, atlas textures to save on shader count. Then optimise geometry so you don't see too much at once (no point batching trees/buildings you can't see as it takes up GPU memory to store the data).
But at the same time you don't want to draw things that can all be seen at once in more than one batch if you can help it. Ie, a street of houses that can all be seen at once may as well be always done in one batch.
Obviously this does all take time and practice to achieve, so as I said I'm not beating any one up over not doing it.
It'll take some time to work out good ways to do it, especially on already made content you are trying to convert!
I just want to make it clear that there IS a big benefit to be found by atlas/batch optimisation. As said, ideally we might be looking at about 50-75 batches for this track and about 100fps vs 25fps on my machine!
It is REALLY well worth persevering over playing with making an atlas, even if you just start with the trees (easy usually) and then combine ALL the tree geometry for the whole course... then chop it up into blocks about 400m long, then add an LOD range of about 800m.
Suddenly you will be rendering about 2-4 batches tops for ALL the trees, rather than maybe 30-40.
That might be 10fps right there, and in practice because trees are so basic in UVW mapping it might only take you 2hrs to do it!
Trees are easy I will admit, but as you start to understand the principle it will make sense and it may even become a fun task to optimise and work out the best ways to do stuff.
Batch optimisation is the only way to get good performance unfortunately... but it's great because it's relatively easy... it's just a task that needs to be done.
I'm busy right now in real life working a Sunday haha, but I will help with making these tracks faster running and help show how to think about batching optimisations for Racer a bit more!
No slur on anyone's work or skills here, just purely an optimisation task that does need to be done and trudged through to get the very best FPS
Dave
Alexander Knoll
NEVER GIVE UP!!
Hello Dave,
i understand why it's (needed) to do some optimizing...and i realy would do it, but as i tried to explain already, all time i try to remap the objects with the atlas texture they disapear in zmod...and i can't see how the mapping move on the object....so it's impossible to place them right...for me...that's why i need help from one who have the software and the know how to do it...the textures are not the problem i can use PS CS2.....
Alex
i understand why it's (needed) to do some optimizing...and i realy would do it, but as i tried to explain already, all time i try to remap the objects with the atlas texture they disapear in zmod...and i can't see how the mapping move on the object....so it's impossible to place them right...for me...that's why i need help from one who have the software and the know how to do it...the textures are not the problem i can use PS CS2.....
Alex
Hi Alex,
I've not really used Zmodeller much though I do have a paid for version of the latest copy.
PS CS2 should be ample for making the atlases, along with the DDS tool you should be able to make really nice atlases
As for the atlas UV'ing part itself, hmmm. I use 3DS Max 2010 here but I know 2011/2012 came with some better UV tools for this exact kind of job... so even for me it's harder work than otherwise.
I know in games like PGR2 for example, they just made everything like we would usually, with small textures and many small items and stuff, and then a big program would optimise/batch/atlas everything and adjust UVs as appropriate.
We don't have that luxury, but in practice it could be an automated process. Even tiled textures can be atlased because our scripts can chop in edges to give UVs something to 'adhere' to as it were.
So yes, using Zmodeller is gonna be tough because it's already fairly tough to do in 3DS Max with some scripts etc.
Just looking now, do you see an 'edit - surface - uv remapper' button?
That looks like it might help you create an atlas. It takes ALL the materials in a selection and re-packs them to fill a square... you can then drag the new UV's around to new areas of the block.
Also just as an important pointer, the trees seem to come in 2 varieties on these courses. Day and night types, I think. Or perhaps it's just front/back.
There is an _A and _C material, you can dump one of them, so any polygons with the _C for example can be binned.
I forget which ones are which but you want to bin all the stuff that isn't a pure X tree.
Also, I think the basic X trees left have co-incident front/back faces so rather than being 2 quads (4 triangles), they are actually 4 quads (8 triangles), so there is a front and a back face overlapping.
They can be trimmed to remove a load of polygons too, so you are left with *just* one face for each part of the X. The shader setting cull=0 means that it can then be seen from both sides.
Not sure how much of this you know but I spent a good while working out how to optimise rFactor track trees as they are very messy as standard for our needs in Racer!
Erm, yes, once you have done all that work then the remaining work is to combine ALL the tree meshes together so ALL the tree materials are in one big object, then use that remapper tool ( seems to auto-fit all the needed uv's into a bigger square), so then you can re-map all the trees in one pass and then I guess into one material.
Then you just need to note which texture(material name) went where on that atlas in the remapper tool so you can put the right tree in the right place
Even if you end up with one 2048x2048 atlas, or 4096x2048, it's gonna be way faster than many smaller textures
I'm sure you will be able to figure it out any way.
Then re-chop up into smaller chunks as necessary so you don't see too much or too little as you drive around the track
I'm far from a Zmodeller expert but that should all be fairly do-able I think...
Anyway, I'll be sure to make a video of me doing these tasks in 3DS Max for the Hockenheim conversion, so hopefully it'll be helpful for you. It'll probably be another month before I get around to that though
Thanks
Dave
I've not really used Zmodeller much though I do have a paid for version of the latest copy.
PS CS2 should be ample for making the atlases, along with the DDS tool you should be able to make really nice atlases
As for the atlas UV'ing part itself, hmmm. I use 3DS Max 2010 here but I know 2011/2012 came with some better UV tools for this exact kind of job... so even for me it's harder work than otherwise.
I know in games like PGR2 for example, they just made everything like we would usually, with small textures and many small items and stuff, and then a big program would optimise/batch/atlas everything and adjust UVs as appropriate.
We don't have that luxury, but in practice it could be an automated process. Even tiled textures can be atlased because our scripts can chop in edges to give UVs something to 'adhere' to as it were.
So yes, using Zmodeller is gonna be tough because it's already fairly tough to do in 3DS Max with some scripts etc.
Just looking now, do you see an 'edit - surface - uv remapper' button?
That looks like it might help you create an atlas. It takes ALL the materials in a selection and re-packs them to fill a square... you can then drag the new UV's around to new areas of the block.
Also just as an important pointer, the trees seem to come in 2 varieties on these courses. Day and night types, I think. Or perhaps it's just front/back.
There is an _A and _C material, you can dump one of them, so any polygons with the _C for example can be binned.
I forget which ones are which but you want to bin all the stuff that isn't a pure X tree.
Also, I think the basic X trees left have co-incident front/back faces so rather than being 2 quads (4 triangles), they are actually 4 quads (8 triangles), so there is a front and a back face overlapping.
They can be trimmed to remove a load of polygons too, so you are left with *just* one face for each part of the X. The shader setting cull=0 means that it can then be seen from both sides.
Not sure how much of this you know but I spent a good while working out how to optimise rFactor track trees as they are very messy as standard for our needs in Racer!
Erm, yes, once you have done all that work then the remaining work is to combine ALL the tree meshes together so ALL the tree materials are in one big object, then use that remapper tool ( seems to auto-fit all the needed uv's into a bigger square), so then you can re-map all the trees in one pass and then I guess into one material.
Then you just need to note which texture(material name) went where on that atlas in the remapper tool so you can put the right tree in the right place
Even if you end up with one 2048x2048 atlas, or 4096x2048, it's gonna be way faster than many smaller textures
I'm sure you will be able to figure it out any way.
Then re-chop up into smaller chunks as necessary so you don't see too much or too little as you drive around the track
I'm far from a Zmodeller expert but that should all be fairly do-able I think...
Anyway, I'll be sure to make a video of me doing these tasks in 3DS Max for the Hockenheim conversion, so hopefully it'll be helpful for you. It'll probably be another month before I get around to that though
Thanks
Dave
Alexander Knoll
NEVER GIVE UP!!
Hey Dave,
i understand every thing you wrote about uv mapping and remapping...thats not the problem....
My problem starts at the moment i assign the new texture to the face or object...at this second the selectet face / object disapear in the window and i can't see where i "move" the new texture....to fit it to the right place...
Sry..can't explain it better...
i understand every thing you wrote about uv mapping and remapping...thats not the problem....
My problem starts at the moment i assign the new texture to the face or object...at this second the selectet face / object disapear in the window and i can't see where i "move" the new texture....to fit it to the right place...
Sry..can't explain it better...
Latest News
-
Why Codemasters Hasn’t Changed Game Engine For F1 24F1 24 uses the Ego technology platform for a 16th consecutive instalment – the game’s lead, Lee...- Thomas Harrison-Lord
- Updated:
- 4 min read
-
How The BTCC and Motorsport Games ReunitedIn a surprise move last week, official BTCC content will once again be present within rFactor 2...
- Thomas Harrison-Lord
- Updated:
- 5 min read
-
Sponsored MOZA Racing & Lamborghini Redefine Racing Boundaries with The Real Race Super Trofeo 2024MOZA Racing proudly announces its collaboration with Lamborghini for the launch of The Real Race...- OverTake.gg
- Updated:
- 6 min read
-
Forza Horizon 5 Apex Allstars Update Adds Five New Race Cars, Plus Yet More DLCA new Apex Allstars Festival Playlist kicks off this Thursday in Forza Horizon 5, joined by a...
- Thomas Harrison-Lord
- Updated:
- 3 min read
-
F1 24's Updated Car Performance and Handling ExplainedWhile we haven’t tested it yet, on paper it sounds like significant changes have been made to...
- Thomas Harrison-Lord
- Updated:
- 3 min read
-
Tim Jarschel Wins 2024 DTM Esports Pro championshipCombining searing pace with consistency, Jarschel took home the title despite a charge from...
- Thomas Harrison-Lord
- Updated:
- 3 min read
-
Embracer Group Splits Into Three – Wreckfest, Milestone, Set For New HomesTwo racing game publishers are now forging their own paths as Embracer splinters into three...
- Thomas Harrison-Lord
- Updated:
- 3 min read