Wheres the new snapshot @jlv

[ColtonD719]

Would be nice to see a decal drop/masking ability make its way in the game.

I really do not know how hard it would be to implement but even games from the early 2000's were achieving a similar concept.
I think it would make spotting new developing lines much easier and would encourage more line formation in racing.

Regardless of how you want to add this feature it is definitely a must in my opinion.

"Jumpin' Jim Rivers drops Vicky the Vixen Steel!" Good ol' Excitebike 64.

Nostalgia aside, I totally agree. I've noticed that in most games (MXGP, MX vs ATV, etc.) the tire mark decals fade out after a certain amount of time, presumably for performance reasons, but even that would help a ton since theoretically by the time the decals fade, the actual terrain could have built up enough to be visible.

This from 2009 seems like a step in the right direction: http://forum.mxsimulator.com/viewtopic. ... 332#p73389

[m121c]

Oh no, not the PBR argument...

PBR is a marketing buzzword that doesn't really mean anything. If it means conserving energy to you, just invert your specular map and multiply your texture map by it. If it means the "Disney shader" (Principled in Blender), I have no interest in doing that. I doubt most people even know what half the settings do. If it just means more realistic graphics to you, yes I want to do that. As an example, I really want to switch from a point light to using an environment map for lighting. That may or may not mean PBR depending on who you ask but it's a much bigger improvement than the Disney shader. Here's something I rendered the last time this came up -



TBH I don't understand why people use Principled even in Blender. The node system is more powerful and has the advantage of actually using well defined terms unlike the Principled shader. Like if I attempted to realistically model a real material by measuring the light reflecting off it from all different angles (i.e. directly measure the BSDF of the material), I could re-create it perfectly using nodes, but it would be impossible using Principled. I don't get what the huge attraction is.

It was only a question, honestly, I have limited experience as when I was phasing out of this game design stuff PBR was just kind of hitting the scene and I was beginning to learn it for funzies. From what I remembered it looked way better (could easily be a product of environment lighting), was way easier/faster to make look accurate, and there was potential to optimize map size. Again, ignorance on my part. Could very well be a product of lighting. That would make sense.

So do you think with implementing the environment mapping and dynamic shadows this game will leap forward 2 decades in graphics with the right artist? Are there trade offs? I'm guessing it's much harder to put into place than I imagine

I do wonder a few things while I have you here...

• - Do you think using the alpha channel for spec maps is the way to go? Most hardly know how to use it. I'm not knocking it.. but it seems that next-gen shaders can utilize reflection and hardness together with an additional map (which... could be an issue of it's own).
  
  - Which brings me to my next point, next-gen shaders use pixel maps for reflection.. which I am guessing is the beauty of using environment map for lighting(?). Do you think geometry defined reflections are the way to go and can achieve the same results?
  
  - As a big part of this discussion was more about optimization, do you think reworking the name/number system for the bike and rider would be beneficial? I think this is a highly underrated feature that is often forgotten about. Maybe it's more a creator misunderstanding... but if we could make the name and numbers fit custom bikes and look good, same with rider model, texture space could drastically be brought down.

Now some ideas I have for rF (thinking out loud):

• - I honestly think there is a lot rF can do to help with load times and performance during races. One idea would be to create a list of acceptable models and provide proper naming conventions for them. This would help not load 40+ uniquely named norm/spec/model files that are 90% exactly the same pixel for pixel and triangle for triangle. This also could ensure model detail limits and the use of LOD's. Let's be honest... even from my side of things where I love making things look cool/detailed, there is no need for that to go racing.
  
  - As a trade of from the idea above, this would mean rF would have to establish models that are open to the public. As much as I support artists selling their work, I also support the idea that it's not entirely community centered. I think with a revamped name/number system the dynamics between creator, community, and racing would drastically change anyway...

Cool to see the game is still be developed. Visually it just seems there has been no progress, which is a bummer. I have no idea the limitations there are, or what is possible here, so excuse my ignorance there. What are you priorities and vision for the game, say, in the next 5 years JLV?

[Atom6246]

One idea would be to create a list of acceptable models and provide proper naming conventions for them. This would help not load 40+ uniquely named norm/spec/model files that are 90% exactly the same pixel for pixel and triangle for triangle.

I could see this being beneficial. I think that's realistic as well. Gear wise, it wouldn't make much of a difference though, right? Only bikes/helmets/wheels. I think the load in issue is scrammed files. So for Kellen's instance it wouldn't benefit enormously as for he would be loading in just as much scrammed files rather than JM's.

[jlv]

It was only a question, honestly, I have limited experience as when I was phasing out of this game design stuff PBR was just kind of hitting the scene and I was beginning to learn it for funzies. From what I remembered it looked way better (could easily be a product of environment lighting), was way easier/faster to make look accurate, and there was potential to optimize map size. Again, ignorance on my part. Could very well be a product of lighting. That would make sense.

PBR means different things depending on who's talking. If it means getting rid of point lights and using environment maps for the diffuse and specular lighting in a way that sort of approximates a scattering function, MXS will have PBR at some point. It's not the term I would use though.

So do you think with implementing the environment mapping and dynamic shadows this game will leap forward 2 decades in graphics with the right artist? Are there trade offs? I'm guessing it's much harder to put into place than I imagine :lol:

Mostly what it'll do is make dull reflections actually reflect something and the dark side of things look less flat since instead of just having a single ambient light it'll be looking up the light level in the diffuse environment map. Just from playing around doing test renders in Blender I *think* it's the most important thing I can do.

Right now it only uses environment maps for perfectly focused reflections and that stuff usually looks pretty good, it's everything else that looks flat. Even that needs to be reworked since it's done in two passes for compatibility with ancient GPUs. This is another place where abandoning pre OpenGL 2.0 will simplify and speed things up.

- Do you think using the alpha channel for spec maps is the way to go? Most hardly know how to use it. I'm not knocking it.. but it seems that next-gen shaders can utilize reflection and hardness together with an additional map (which... could be an issue of it's own).

Is there a good reason for that? Using the alpha channel for hardness saves a texture and there's a limit on the number of textures you can use in a single shader. I think there were some cards where the limit was 4 when I wrote the shaders, which would have given me 1 for diffuse, 1 for the normal map, 1 for spec map, and one free which I wanted to use for an environment map when I eventually switched to single pass reflections. You definitely don't want to just waste one for no reason.

- Which brings me to my next point, next-gen shaders use pixel maps for reflection.. which I am guessing is the beauty of using environment map for lighting(?). Do you think geometry defined reflections are the way to go and can achieve the same results?

Reflections are done in the fragment (i.e. pixel) shader. It's only done per vertex for cards without GLSL shaders, which I'm going to stop supporting soon.

- As a big part of this discussion was more about optimization, do you think reworking the name/number system for the bike and rider would be beneficial? I think this is a highly underrated feature that is often forgotten about. Maybe it's more a creator misunderstanding... but if we could make the name and numbers fit custom bikes and look good, same with rider model, texture space could drastically be brought down.

Probably would be a good idea to add a name to the built in number plates. Do you think it would actually be used if it were like that?

[Wahlamt]

- As a big part of this discussion was more about optimization, do you think reworking the name/number system for the bike and rider would be beneficial? I think this is a highly underrated feature that is often forgotten about. Maybe it's more a creator misunderstanding... but if we could make the name and numbers fit custom bikes and look good, same with rider model, texture space could drastically be brought down.

Probably would be a good idea to add a name to the built in number plates. Do you think it would actually be used if it were like that?

If there was a really seamless way to just slap that on and make it look good every time, then yes. Otherwise no

[KTM57]

I would say my chances of using it would be near zero. None of us even use the numbers.

[Jeremy150]

Only way it would work in my opinion if there was somehow a way to use custom fonts, which I know isn't really a possibility when dealing with licensing. Kind of a bummer because I could see that as being a pretty decent optimization with texture sizes. People love crispy numbers

[Jones221]

how to change numbers/font

[Wahlamt]

Added new numbers in the latest stock model replacement. But that's only 1 variant...

[m121c]

Is there a good reason for that? Using the alpha channel for hardness saves a texture and there's a limit on the number of textures you can use in a single shader. I think there were some cards where the limit was 4 when I wrote the shaders, which would have given me 1 for diffuse, 1 for the normal map, 1 for spec map, and one free which I wanted to use for an environment map when I eventually switched to single pass reflections. You definitely don't want to just waste one for no reason.

This is good information to know, I did not know there was a limit on some cards. My reasoning was that typically you can expect higher file sizes with the alpha channel.

Reflections are done in the fragment (i.e. pixel) shader. It's only done per vertex for cards without GLSL shaders, which I'm going to stop supporting soon.

Okay, either it's been entirely way to long since I have made anything or Im really not understanding you here. Just to be clear, by reflections I meant glossiness, we can control that without vertex definition? I can remember explicitly having to define glossy parts (plastics, chrome, etc.) with geometry last model I made. Maybe if I can give you an idea of what effects I am thinking about... What I would want to do is say have a aluminum frame. I would love to be able to define the upper part of the frame and wear areas to feature a much more smooth "chrome" glossy/reflection while the raw casting parts are much rougher surface. Or say you have a very smooth metal like an exhaust header. If you wanted to have like a dust/dirt overlay and not have a glossy layer over something that isn't glossy. I don't know the technical side on how to make that happen... every attempt I made in MXS resulted in a flat looking frame with a 10mm thick coat of SC1 over it.

- As a big part of this discussion was more about optimization, do you think reworking the name/number system for the bike and rider would be beneficial? I think this is a highly underrated feature that is often forgotten about. Maybe it's more a creator misunderstanding... but if we could make the name and numbers fit custom bikes and look good, same with rider model, texture space could drastically be brought down.

Probably would be a good idea to add a name to the built in number plates. Do you think it would actually be used if it were like that?[/quote]

It would depend greatly on how it looked and how the community utilized it. Gear would probably be the tricky one due to how the normal maps change, but if you could get it to somehow overlay and look as if you did it yourself... genius. If done right, I definitely think it would, here is why:

• 1) No need for templates anymore unless making major customization like graphics, plastic color, etc. The general MXS consumer would just be able to download and personalize a bike/gear set without any hassle, they could have the latest and greatest. No need to ask anyone to make it for them.
  
  2) Creators don't have to worry about files going to the wrong people. I think this would promote much more releases... they can still sell their source files if they so chose I guess, but the content still flows.
  
  3) It allows rF or any other racing org to define standard models and enforce name/numbers to be used. This is at the core of why it would be used. If rF has a standard set of models and proper naming convention, there would be no wiggle room for people to have 8 rider team packs with 16 (gotta have the red plate bikes just in case ) unique 4k diffuse maps with each persons name/number on them. Each team would have one 250 and one 450 diffuse map which would then use the standard normal/spec maps defined by rF. I would love to see the memory savings on something like this... I bet it would be astronomical.

Would it be useful at an individual level.. probably not, but does that matter? I mean if I want to play by myself in single player with a complete tricked out custom bike not using name and number on anything because I did it in photoshop... it doesn't really hurt anyone. But, if I am in a server or racing rF... I will want to use it because I will want everyone to see me and my number. I think the biggest thing with this type of feature is the knowledge base needed to have creators be able to re-create it as they make new models.

[hvpmvp]

Okay, either it's been entirely way to long since I have made anything or Im really not understanding you here. Just to be clear, by reflections I meant glossiness, we can control that without vertex definition? I can remember explicitly having to define glossy parts (plastics, chrome, etc.) with geometry last model I made. Maybe if I can give you an idea of what effects I am thinking about... What I would want to do is say have a aluminum frame. I would love to be able to define the upper part of the frame and wear areas to feature a much more smooth "chrome" glossy/reflection while the raw casting parts are much rougher surface. Or say you have a very smooth metal like an exhaust header. If you wanted to have like a dust/dirt overlay and not have a glossy layer over something that isn't glossy. I don't know the technical side on how to make that happen... every attempt I made in MXS resulted in a flat looking frame with a 10mm thick coat of SC1 over it.

A pretty simple way to do this would be with a glossiness map. It's fine if you don't want to put pbr in mxs but can we at least get something like controlling gloss with maps if it's even possible in this engine, JLV?

[jlv]

Only way it would work in my opinion if there was somehow a way to use custom fonts, which I know isn't really a possibility when dealing with licensing. Kind of a bummer because I could see that as being a pretty decent optimization with texture sizes. People love crispy numbers :lol:

I could make it look for custom plates in a folder somewhere based on the rider's name and number. Something like "@customplates/<rider name>-<number>.png". Of course they'd probably all wind up being 4k so it wouldn't be a win on texture size.

Might be problems when sticking a name in that texture with current models since they only expect a number.

Okay, either it's been entirely way to long since I have made anything or Im really not understanding you here. Just to be clear, by reflections I meant glossiness, we can control that without vertex definition? I can remember explicitly having to define glossy parts (plastics, chrome, etc.) with geometry last model I made. Maybe if I can give you an idea of what effects I am thinking about... What I would want to do is say have a aluminum frame. I would love to be able to define the upper part of the frame and wear areas to feature a much more smooth "chrome" glossy/reflection while the raw casting parts are much rougher surface. Or say you have a very smooth metal like an exhaust header. If you wanted to have like a dust/dirt overlay and not have a glossy layer over something that isn't glossy. I don't know the technical side on how to make that happen... every attempt I made in MXS resulted in a flat looking frame with a 10mm thick coat of SC1 over it.

What you mean is you want the lighting controlled by the hardness setting in the spec map to reflect the environment map instead of a point light. That's the plan. Right now it only uses the environment map as a second pass for materials that are set to reflect. The specular lighting is a point light.

A pretty simple way to do this would be with a glossiness map. It's fine if you don't want to put pbr in mxs but can we at least get something like controlling gloss with maps if it's even possible in this engine, JLV?

That's what the alpha channel in the spec map does.

[Jeremy150]

That's what the alpha channel in the spec map does.

I've never been able to wrap my head around this. Here's a couple tests I ran.

I used a black diffuse with a norm and this spec map

Giving me this result


Here's an inverted version of the same spec map

Giving me this result



However as soon as I turn up the "mirror" setting in blender I get this result.

(all tests done with the 2.79 export script)
I've always just had to model in geometry if I wanted specific parts of a mesh to be glossy/reflective

[m121c]

What you mean is you want the lighting controlled by the hardness setting in the spec map to reflect the environment map instead of a point light. That's the plan. Right now it only uses the environment map as a second pass for materials that are set to reflect. The specular lighting is a point light.

Exactly. Awesome. I am excited for that day to come.

Just brainstorming here, is the a way you can have the game somehow take a name/number png and overlay the gear norm onto it so it looks like you just put it right on the diffuse map? Would this cause loading/performance issues?

I'm really curious how the MX vs. ATV series had it so you could type your name/number in and it would overlay on to your rider no matter the gear brand you used. Would you have any insight or thoughts on that from a more technical prospective?

[Jeremy150]

Maybe I'm, just misreading what you said JLV, but I thought you could only control the specular hardness in the alpha.