Search

[wallworm]

Well I figured the problem out... the code I added for infodecal looking for the closest brush and orienting to it was inappropriately being applied to ALL entities. I just loaded the fix for that.

EDIT:

So I expect the props to be all correct now.

In terms of the long loads with a prop library... I have an idea what is causing this. My best advice at the moment is to click the Prop Library From VMF button in the VMF Importer before importing the level, keep those objects in the scene, then import the level. This might reduce file system lookups per-prop in the VMF importer as I don't think this method will use XRef objects.

I'll optimize it for less file lookups as that's probably the problem.

[SairesArt]

So I expect the props to be all correct now.

Indeed, they are all fixed.
However, the Overlays still float in space and decals still don't import.
Used the last official build from today.

[wallworm]

In my simpler tests all the overlays and decals are mainly correct. So I will have to test more complex scenes now.

The position of the overlays/decals is directly based on where it's origin is inside the VMF. Hammer often displays the decals far from their origins. This is something that I'll address in the plugin (see below).

Overlays are almost always correct for me. But their accuracy in the viewport is dependent on their origin being close to the surface they are supposed to be applied to and the number of brush faces the overlay is applied to (if the overlay is using multiple faces or has faces that no longer exist, there can be problems--as the overlay aligns itself to the normal of the first face in the sides it is assigned to).

Decals are often aligned incorrectly because the decals are just points in space and I have to get the closest brush based on surface (which can be a guesswork and can have more than one valid brush to choose from). The fastest way to do this uses an intersect() function... but this is flawed because the decals are planar in WW ... so I need to rework it some.

Even once I get it "done" the decals are still planes... so if the decal needs to wrap on multiple surfaces... it won't look right. I've started a new plugin for decals in Max that will handle this (and more). As it will be a general purpose decal plugin and is going to take me a week (or more) to develop, it'll be a commercial plugin that will be no more than $10.

[SairesArt]

thx, you deserve a cookie :]


Would it be possible to revert to how Overlays were handeled prior to 1.62? aka, always correct position, but wrong scale and rotation?
The Map import is fixable with those, but with the wrong positions now it's too inconsistent.
But keep the awesome VMF import code, that for whatever reason does not have missing brushes anymore and is stable?
(also the disappearing verticies on small brushes with "validate geometry" are still there)

[wallworm]

As for the positions, I'll simply need to find out why they are currently off for you. The position of an overlay should not have changed from before... so I will just find out why it is incorrect in your case (I'm not getting any overlays with incorrect locations in any tests ATM).

In terms of  the "validate geometry" error. I actually recommend NOT using that function. See if the brushes are all correct without that option. The validate geometry function is destined to be removed eventually as the errors that it was used for should be disappearing. I'd leave it off. After an import you can click the "Select Imported Geometry that Needs Attention" button in the VMF Importer to see brushes that the importer thinks might be wrong--and you can fix as needed (if needed).

At this point, I import with:

Use Default Brush Generation = ON
Validate Geometry = OFF

I'm off for the day to go fishing with my son, so I won't have any updates until tonight or tomorrow.

[SairesArt]

I'm off for the day to go fishing with my son, so I won't have any updates until tonight or tomorrow.

Have a fun day :]

[wallworm]

So I've figured out the overlay positions problem. info_overlays have 2 parameters that relate to their position in world space. Like all other point entities, they have an origin property that is their position in the world. But they also use a property called BasisOrigin. The BasisOrigin overrids the origin. IN all the files I've tested, these two values are identical. But when I imported your level, the Z position is inverted (so the origin might be [128,64,512] but the basis origin is [128,64,-512] . So now I know. I'll fix this in the next update.

[SairesArt]

So I've figured out the overlay positions problem.

My body is ready. Hope you killed the local fish populus.

[wallworm]

was busy for a couple days. And tied up ATM... I haven't forgotten about this. I'll post a fix this week.

[wallworm]

OK, I believe you can now get all the correct positions and usually the correct orientation. However, there are times when the overlay is flipped, so you may need to rotate some on occasion and/or flip the UVs.

[SairesArt]

OK, I believe you can now get all the correct positions and usually the correct orientation.

Many Many thx.
I see your confidence has risen again as you dropped the parse retries to 0 :D

Well, it's finally as good as I needed it to be.

Bugs include:
-Overlays are Double or half the actual ingame size
-rotation arond the X axis being -33.164 (for whatever reason) Its no problem to set it back to zero, but a couple of overlays are just randomly rotated around thex axis by 33.164 degrees
-decals still don't import, although I set it up correctly

[wallworm]

Thanks for the response.

I was importing the full level from what you sent me and the overlays and decals are all importing for me (I'm importing from the full scene). Are you trying it from the same full file? It may not work for a file with only decals... it might need to include the brushes in the imported vmf.

The rotations of the overlays is still something I intend to look at. I'm not sure I'll get it 100% because of how the data is stored/interpreted/converted. The issue, I believe, is that the overlays are determined in world space but then also determined by the U/V scaling ... and there is some more math I haven't truly figured out when aligning it to a face in the correct coordinate system. I think the issue will be solved by the decal plugin I'm working on that won't need to worry about face orientation (and order of the vertices in the face).

In terms of the overlay size, it may be related to which axis is used. In the tests I've done in my own scenes, the sizes seem correct. So I haven't determined what is the cause for some to be correct and others not.

[SairesArt]

I was importing the full level from what you sent me and the overlays and decals are all importing for me (I'm importing from the full scene). Are you trying it from the same full file? It may not work for a file with only decals... it might need to include the brushes in the imported vmf.

I tried the full map two times, the decals just always stay proxy objects.
It just says infodecal in the propties, so it's not a Base FGD parse issue.

(different map, but same for others)

[wallworm]

When you click Wall Worm > Wall Worm Level Design > Point Entities, does it let you create a infodecal or prop_overlay ? (although in WW you'd want to use Worm Face to create both, this is just a test to see if the entities are actually available). If not, WW embeds the raw entity data (if you right-click the imported decal and choose Object Properties and the User Defined Tab, you'll see the embedded data).

WW won't do all the necessary things for importing decals/overlays with embedded data as it was going to take more time to update the legacy entity info import code--and if the entity cache is valid it isn't necessary anyway. Supporting the legacy entity info (that is based on support for Maple 3D's Convexity entity format) is probably not something I will continue to do with updated functions.

So if WW doesn't have the entities for those, then the entities do need to be updated/parsed. However, if the entities are parsed, then it might be a difference in the entity data in the entities in your FGD than those I've ever dealt with. I'm currently testing with the CS:GO FGD. In that case, send my your FGD files you are using.

[SairesArt]

ye i can create it.
I have also deleted the MOD's FGD, since I don't need its spawn entities.
It still wont import decals exept squares

So i really only use the base.fgd
considering the proxy imports corerctly, the fgd shoudn't be the issue.