Model oppacity (soluted)

    So I've been doing some props for a recent project I'm working on with fellow mapper penE and just two days ago compiled this lovely plughole for Source-Engine (Ep1 Version):

    [Blocked Image: http://www.abload.de/img/zwischenablage0244e.jpg]

    So as you can see there's a little Problem with oppacity. The end of the model (the grey to black part) shines through all the other surfaces although they all share the same VTF/VMT and there's no code in the VMT that could tell the Model to behave anything like this. There's an Alphachannel on the whole thing to get that slime part at the end possible and for a fence which is in the plughole (which you can't see because of the oppacity error).

    Any idea on what could be causing this?

    (Just fyi: The Model is "part" of this texture (remake): [Blocked Image: http://xs323.xs.to/xs323/08021/out_wall6.jpg])

    Found the solution after reading the (whole) Valve Dev Wiki second time:

    Isntead of $translucent you have to place $alphatest into the VMT which is not as precise as the $translucent shading but therefore has less bugs with multiple alpha-overlays in one model.

    [Blocked Image: http://www.abload.de/img/zwischenablage026s5.jpg]

    (somehow the alpha reading is now back to 1 bit it seems but i'll find a fix for that hopefully)

    as you found out by your self:

    8bit alpha sorting isnt supported by any current game engine. it costs lots of hardware and doesnt make it.

    there could have been other solutions than just making it alphatested:

    for example having 1 vtf and 2 vmt. 1 vmt without $translucent and the other one with $translucent. applying translucent material to the slime wouldnt destroy all sorting since the other polygons are "solid" for the filling algorithm. but this solution should only be done if you really insist on 8bit alpha since 2 vmt files equal 2 render batches. the more batches an image needs to be completly rendered the slower everything gets.

    Will have a look into that. Thanks hessi. The problem with 1 bit is now that I wanted to cover the apprupt ending of the model with some kind of plants painted upon the fence and a good normalmap.

    Did you put $mostlyopaque in your QC file? That usually tells the engine that you model has translucent parts and I *believe* makes the engine do what hessi describe, i.e. render the transparent parts first and then the solid parts after which should help with the z-order problems.

    Will try out that one!

    Edit:

    Doesn't work.

    Now I'll try again hessi's approach but last time XSI Crashed with that or it wouldn't accept Transform Freeze

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login