Hello out there,

I don't know if something is in the engine at the moment and it is just an Idea. Materials allow different Techniques to render a modell.

It would be cool if you can make the following:

Technique1
{
....
}

Technique1_LOD1
{
....
}

Technique1LOD2
{
...
}

and finaly a technqiue:

fallback

no you could implement some new variables like d3d_shaderlod0 - 4. wich tells the engine in wich distancy from the current view the material Technik has to change to another.

This would also cool for the chunked terrain because you could simply reduce the size of the texture detail for chucks far away from camera.


AND YES: I know you could implement this by c-script and I have done it and saved up to 20 FPS in a single view application BUT: You can't do that with multiple Views in C-Script at the moment.

So Conitec would something make sense ? And will you do it ?

regards
XeXeS

Alternatively you can do this in the shader itself, just find the distance and branch out.

This is no workaround if you use ffp.

@Matt_aufDerHeide:

When ever I see you in this forum you came up with realy stupid workarouds. Your solution may work but isn't the best. In your thing the shader have to set up calculate the distance select the right calculations and furthermore. You've to do this per Pixel if you want to use maybe only one blend texture instead of two.

Also you've to set up all the eventually not needed textures for the effect wich will maybe cause more bus bandwidth.


Just believe me I know what I say and please do not post such stupid workarounds if it is much slower. I must say sometimes I cant believe wich nonesense some users telling in this forum.

regards xexes.

Quote:

---

Just believe me I know what I say and please do not post such stupid workarounds if it is much slower. I must say sometimes I cant believe wich nonesense some users telling in this forum.

---

Lol. You have some mental problems. I was just suggesting a method that can work now without any new updates. I have done this in my own experiments with good results.

Xexes, dont use your elbows too often. Sometimes you hit yourself when you are too busy with them.

Matts suggestion could have been mine suggestion - MAYBE it will be implemented soon, but MAYBE youve got proper results if you do (you call it workaround, I call it improvisation) something similar on your own ... you say you have knowledge ... use it!

I dont want to blame you, I just want you to know that its a bit difficult for everyone to handle with people like you which think they are always in a race or in a competition or something else.

Live long and in prosper
Christian

From the first post, the feature-request was addressed to conitec in the first place, not for a poll - and in fact, should be usefull for many people.

What Matt posted is a workaround for some cases, nothing more. You will really soon get problems when using that method for more then tests, especially, if you target for lower hardware - if you can use it at all. On the other hand, your post sounds more like a final method or solution, not like a workaround.

Why will you get problems? Doesnt early exit feature of 2.0 allow stuff like this?

Yes, kind of - but dynamic flow-control is only avaiable on 2.0x. Even if you can use the dynamic branching in the pixelshader, it is not very efficient to do the technique-branching on a per-pixel basis. Even when that works efficient enough, you'll still get problems with the guaranteed 96 pixelshader instruction.

That makes sense. Anyway, i wasnt saying that Xexes' idea wasnt a good idea, just that there is an alternative that may work for some purposes.