It probably won’t be of help for anybody really, since it is a DevC++ project and basically conforms to C++11, but maybe that isn’t such a big deal for somebody who is desperately trying to find out stuff about Goldsource/Quake map generation?! IDK, go crazy on it. Good luck!
See the version’s overview page for more detailed information about the new additions and changes.
In this release I added a bunch of important features that I wanted to have in there for a long time now. Let’s take a look at the main changes.
Finally I added the ability to read WAD3 files (Goldsource WAD files), so one of the most cumbersome downsides of the tool is a thing of the past now.
Only thing you need to do is to add the files paths to WADList.txt in the WAD folder or place copies of them in the said folder.
FGD File and Setting Entities
As a first alternative to using preset files for curve generation I now added 3 entities for Goldsource editors that enable you to modify all of the currently available commands for M2C.
Detail Object Processing
It is now possible to take anything from the level and align it along a curve object. I also added several possibilities to modify the settings for each of such a detail group individually. First and most relevant one being the info_detailgroup entity from the new FGD.
Take a look at the new versions overview page for more information and walkthroughs.
GUI tool still cooking
voidkeeper is currently working on a GUI tool for M2C. It generates the necessary preset files for curve generation based on the users choices and sends it to the M2C executable afterwards.
This would be the second alternative to creating preset files and probably one of the most attractive, too.
At this point I want to shout a loud THANK YOU at voidkeeper and wish him all the best for his current project Occult Scrim:
Added WAD3 File Support
Added Detail Object and Point Entity Processing
Added FGD File and Setting Entities for GoldSource Editors
Getting close to release: I more or less finished some remaining issues with the new feature (detail objects).
As you can see it is not a big problem to generate complex curved objects with a lot of details, while still being able to preserve some polygons. The last part is of course spoken relatively, since scenes like these will always consume more polygons than simpler ones and thus have to be used carefully.
The curved corner part of this bridge was generated from this simple map scene:
Entities like cyclers, NPCs and thelike are being rotated and aligned along the curve as well. This behaviour can be deactivated, too.
The desert scene in the gallery was compiled with UnkleMike’s modification of the VHL Compilers, which enables models to cast shadows.
After weeks of annoying guesswork I was finally able to implement proper rotations for point entities. Now if you ask yourself “Isn’t it just like rotating a vertex in 3D?”. Well, not exactely. Let’s just say I now know a lot more about Euler angles and rotation matrices than before and I am “absolutely” sure that will be of help in my future life. Yaha.
Anyway, when including detail groups into a source map (loose objects that are not meant to be a part of the curve itself), their member entities can be automatically rotated both along the Pitch and Yaw axis, which means the objects will follow the curve entirely in direction and orientation. This can be helpful to generate specific scenes I can imagine.
Realistic scenes like the one I added.
You know. Realistic stuff like that.
I think I will be able to release version 0.5 in the next couple of weeks.
I am still working on the new feature, which will enable you to generate additional detail objects along curve objects.
I had a hard time figuring out a specific calculation method, that actually wasn’t even necessary in the end, so there went one or two weeks of depressing work.
Pitch for Ramps
As you can see on the GIF I am including a pitch for ramps, which will make sense in some situations, where you want the detail object to actually follow the ramp completely. It won’t produce perfect alignments for every setup though.
Also at the moment the Origin of a detail object is its bounding box center point. Later I might include a way to use actual Origin brushes.
Creating Detail Objects
Detail objects are being created in the same MAP-file as the curve source objects. In order for Map2Curve to know which brush belongs to a detail object group, it has to be given a new Key and Value.
Currently it is done like this:
Key: m2c_dgroup Value: CustomGroupName
A detail object, or rather a detail object group, can consist of multiple different entities. Each one needs the same group name ofc.
What about Point Entities?
I am on it.
Entity angles and numeration
I am aiming at automatically generating rotations for point and solid entities, that use the “angles”-key (NPCs, weapons, light_spot, func_door_rotating, etc.).
Also I want add a function to number entities consecutively (button01,button02,…). For this the tool will look for keys like “target” and “targetname”. This makes generation of functional setups – that depend on individual targetnames – a lot easier.
a little preview on the next feature for version 0.5 of Map2Curve:
Detail objects can be anything that is not meant to be turned into a curve, but is still supposed to be aligned along a curve object.
This will include point entities, too, as well as entire solid brush objects, for example lights, cross beams, ropes, etc. Anything you might want to “decorate” your curve object with.
Of course there will be certain limitations again, but this is at least meant to be a huge relief for certain mapping tasks. Primarily it eliminates the need for manually doing it by using “Paste Special” in an Editor.
I have accomplished all of what I was aiming for in this release, including the first version of the path extrusion feature and a complete overhaul of the texture alignment on ramps, which, as I posted recently, now works like the UV Lock feature in JACK.
Next thing I will do is probably creating a few video tutorials and updating the documentation.
As for the rest…
New Feature: Added path extrusion
New Feature: Added World-to-Face alignment conversion on map load
Overhaul: Complete overhaul of the texture alignment for ramps
New settings: p_reverse, p_cornerfix, p_split, ramptex
Added triangulation for 5 sided brushes
Triangulation now default for ramp generation
Fixed minor texture misalignment issues
Future planned features:
Handling of fixed level components like smaller detail objects (lamps, guard rails) or even whole level parts. At the moment you would achieve those by using special paste in an editor like JACK
“Real” path extrusion that works by intersecting lines, like you would usually have it in 3D software.
Texture alignment on ramps now finally working
The texture alignment on ramps kept bothering me for weeks now and I finally decided to use a method that does the same as JACK’s UV lock feature. It basically just pulls the texture into the direction you’re moving the vertices to and preserves the original texture shift, while adjusting its scales to fit the new face length.
While this is the best method for texture shift preservation, it will also lead to a certain distortion, when the slope angle is very steep. The pros of that method outweigh this con though.
Initially I ran into problems when I tried to compile the pipes in the upper example. I realized that this was caused by them having floating point coordinates, so I was able to compile the demo map without any compiling issues in the end, by just rounding all coordinates to integer numbers – AKA snapping them to the grid – using “round 1” during the generation process.
Doing this won’t have any noticable effect on the texture aligns or shifts, which is absolutely brilliant, because having a managable mesh is important when working in any editor. Of course this will also break any mesh with sloped but non-triangle faces. This should be kept in mind when rounding meshes that actually don’t need to be triangulated.
Alternative texture alignment
Anyway, as an alternative I also included the old method I was working on. It can be used in situations, where crossing details on the horizontal texture axis aren’t that bad, but having an upright vertical texture align is relevant for a natural look… or whatever.