BinEdit 2.3.1

Homepage: http://binedit.com
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.0

Post by Fila »

Going to post it here before I forget.

So basically, this is not a new material. It's a tweak to the original glass material HOWEVER inside binedit I gave it its own button called Mesh Preset to differentiate the behaviour. Basically, glass preset turns ANY texture into glass. This is useful if you have trucks with one solid texture, any texture, and you just want to do a quick update to turn it into glass without doing any additional texture work.

This was by design incompatible with mesh windows. The reason why going the material route was the correct choice, each material has a certain amount of memory and you can add different behaviours, the glass preset had the "Texture alpha = solid" flag which was never used. What this flag does is it makes only the alpha channels into glass while preserving everything else. The reason I added a different button for the preset is simply to differentiate this particular behaviour, otherwise you can just select glass preset and turn the flag on :p, no new faces, no new coding actually, just had to enable to flag (well i needed to do some fixes in the engine but that's another story).

So the difference with this is that you obviously have to author the .raw/.png file properly with alpha channels for it to work correctly. There is a caveat though, if you want the glass to be uber reflective, the mesh will be uber reflective too. It's simply not going to be able to differentiate but I'm pretty sure when you do a mesh like this you assume there isn't an actual window there :)
So you can play with the parameters to get the right feel and this goes for the glass window too. the parameters control how much reflectivity should there be, how see through the glass is (so to the point where you don't see the glass material at all, pure transparency) etc. Just toying around with the settings I made that mesh look like it's an actual mesh with no window.
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.1

Post by Fila »

https://binedit.com/downloads/BinEdit231.zip

Added the aforementioned material spin-off, Mesh Preset. To make Rudee happy :p

Also, I added the truck 2.1 compatibility to the Truck Editor. So now you can finally load a 2.1 truck and can set the 2nd set of axle bars straight from the editor, no more having to do manual afterwork!!!!
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.1

Post by Fila »

Also Rudee, just so you know, 64x64 .raw/.png textures can now have normals. The only 64x64 .raw textures that cannot have normals are the terrain ones. Those need to be .png otherwise it won't work.
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.1

Post by Fila »

Forgot to mention. Also added the ability to load the different tires in the truck viewer. So it mirrors the way the engine works, if it finds the 4 different tires with the correct endings, it will load them in the preview.
User avatar
OG_RuDeE
Member
Posts: 277
Joined: Fri Apr 28, 2023 4:11 pm

Re: BinEdit 2.3.1

Post by OG_RuDeE »

Here's a fun one for you. Load this model in BinEdit. Look at the tail gate. All textures aligned correctly. Save it using BinEdit, and reopen. The textures on the tail gate get twisted by the save.
You do not have the required permissions to view the files attached to this post.
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.1

Post by Fila »

Redownload. Should be fixed now
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.1

Post by Fila »

That also suggests a design that needs no authoring flag at all, which matters because the surfaces that most want this (tyres, bed — legacy 0x18 facets found by _N convention) carry no material record, so a MRGLMAT2 flag couldn't gate them anyway.

Detect it per-map at registration: hdNrmRegister already has the decoded RGBA in hand. One pass over it, once per load, classifying the alpha as absent / uniformly opaque / genuine content. Then:

No alpha channel (BFSSW1_N, CJTRAILR_N, TEST1024_N) → reads 255 → treated as "no spec map" → today's behaviour exactly.
All-opaque alpha (GD-W1_N, ROCK4_N) → same → tyres keep the highlight we just fixed.
Genuine variation (ARBMONSTER_N, 0–128) → spec mask active.

Immune by construction rather than by a flag someone has to remember, and it means black = fully shiny, white = flat can be exactly the requested polarity — the backward-compatibility problem only existed because "no alpha" would have read as white, and now "no alpha" doesn't read at all.

The engine already classifies textures this way (classifyGlowTexture), so it's an established pattern rather than a new one.

Two things to tell the requester honestly:

If their generator packs height in alpha, that's the collision. ARBMONSTER_N's 0–128 range looks exactly like a height channel, and under this feature it would become a roughness channel instead. They'd need to author alpha deliberately as roughness. Worth confirming what's in there now before I build it — if it is height, everyone using that generator gets an unintended mask, and I'd add an INI kill-switch for it.
On shiny facets the mask is partial. The base per-vertex specular is folded into the intensity by the vertex shader and can't be separated per-texel; the mask fully controls the bump's specular but not that. On flat facets — tyres, bed, most legacy art — there's no base specular, so it's fully authoritative. Their two problem surfaces are both in the fully-authoritative case.
User avatar
OG_RuDeE
Member
Posts: 277
Joined: Fri Apr 28, 2023 4:11 pm

Re: BinEdit 2.3.1

Post by OG_RuDeE »

So, this looks to be about using alpha channel of the normal map as specular control. Is there a question in there for me? The alpha channel of the normal map in evo 2 (where arbmonster_n came from) was not height, it was specular.
User avatar
OG_RuDeE
Member
Posts: 277
Joined: Fri Apr 28, 2023 4:11 pm

Re: BinEdit 2.3.1

Post by OG_RuDeE »

Fila wrote: Mon Aug 24, 2026 4:45 am Only the 0x18 face type yes. Claude said it was reading them flat.
Facet normals: read flat. Literally a,b,c = 0,0,0 on 1764 of 1765 facets. Nothing to invert — there was no direction stored at all. The engine's FLAT path reads that straight into the GPU normal with no validity check, which is why the bed's relief died.

Vertex normals: neither flat nor inverted. They're perfectly well-formed — every one exactly unit length (65535) — and coherent. They just point along the wrong axis. For the 27 interior bed vertices:

mean |nx| = 0.042 mean |ny| = 0.057 mean |nz| = 0.995

The bed is horizontal, so geometry says every one of those should be (0, +1, 0). Instead the vertical component sits in Z:

vert 89 ( 0, -5100, 65336) -> ( 0.000, -0.078, 0.997)
vert 90 ( 0, -9234, 64881) -> ( 0.000, -0.141, 0.990)
vert 652 (-3447, 0, 65444) -> (-0.053, 0.000, 0.999)

That's a Y/Z swap — the ILIST is in a Z-up frame while the vertex positions are Y-up. An inverted normal would still have |ny| ≈ 1.0 with the sign flipped; these have |ny| ≈ 0.06, i.e. perpendicular. That's why it read as "sideways" earlier.

Ford-chan - i found the bug. It was smoothing, it was getting secretly disabled.
So, as far as I understand, our exporter doesn't write a normals block for any face type other than 0x40. Normals are determined by the winding order of the surface in game for those face types, right?

If it is something we need to change in the exporter and not something fixed engine side, won't that mean that any old models with 0x18 face type will not have working normal maps if they are added later?

I'm confused.
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.1

Post by Fila »

Not sure, I had the AI scan my folder and said he hasn't found any other trucks with broken normals.
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.1

Post by Fila »

OG_RuDeE wrote: Mon Aug 24, 2026 9:06 am So, this looks to be about using alpha channel of the normal map as specular control. Is there a question in there for me? The alpha channel of the normal map in evo 2 (where arbmonster_n came from) was not height, it was specular.
The question is if the change in the quote is what you are hoping for to happen. Want to make sure I make the right change.
User avatar
OG_RuDeE
Member
Posts: 277
Joined: Fri Apr 28, 2023 4:11 pm

Re: BinEdit 2.3.1

Post by OG_RuDeE »

On shiny facets the mask is partial. The base per-vertex specular is folded into the intensity by the vertex shader and can't be separated per-texel; the mask fully controls the bump's specular but not that. On flat facets — tyres, bed, most legacy art — there's no base specular, so it's fully authoritative. Their two problem surfaces are both in the fully-authoritative case.
I think so. It's kind of hard for me to parse the above quote. What I'm hoping for 0x29 faces is that no alpha will act as you have it now. Fully black alpha will act as you have it now (I can't imagine people want even shinier surfaces, right?), and fully white will be totally flat, similar to 0x18 faces now. By choosing shades in between white and black will turn up the shininess as you tend from white to black: so darker = shinier and lighter = flatter. I would still want the other channels of the normal map to show up as they do now, so bumpiness is not affected by the alpha channel.

I would leave 0x18 faces as they are currently, I guess ignoring any accidental alpha in the normal map. My assumption is that authors who chose 0x18 wanted those parts flat shaded (now with bump from normal texture if one is added).
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.1

Post by Fila »

I silently updated BinEdit.

I realized there was a glaring miss in BinEdit and that was, if you created .pod with BinEdit (model or truck) it wouldn't automatically fill the pod with the _N or _AO texture. Now it does. As long as you have the files in the ART folder at creation (when you build the pod) it will automatically load them in.

I am also seriously considering making an MTM2 engine tweak (together with all the authoring programs) to maybe split the Art folder. Mine is 200k files, it's ridiculous at this point. The double raw/act is a pain in the butt.
User avatar
OG_RuDeE
Member
Posts: 277
Joined: Fri Apr 28, 2023 4:11 pm

Re: BinEdit 2.3.1

Post by OG_RuDeE »

You're sort of past this point, but my workflow with BE is to have a single project going in the ART, MODELS, TRUCK, etc.. folders at a time. When I go to switch projects, I zip all those directories together. Then I delete them from the BE folder. Then what I want to work on next, I unzip my stuff into BE, and start there. Easy enough for trucks or a few models. For tracks, it's a whole other ballgame!
User avatar
Fila
Member
Posts: 2061
Joined: Mon Jul 02, 2001 2:01 pm
Location: Lost in Translation
Contact:

Re: BinEdit 2.3.1

Post by Fila »

Silently updated with the Truck Name length warning.
And actually added a bunch of warnings whenever trying to create a truck.

Otherwise nothing new added.
Post Reply