[FTEQW][WIP] craFTEr - realtime game editor for FTE

[toneddu2000]

[Spike]

brush_create(world.modelindex, brushFace, brushFace.length, CONTENTBIT_SOLID);
(note that brushFace.length == 6, it just looks a little cleaner to avoid magic numbers. however, chances are that you'll need more faces per brush at some point, this argument should of course be the number of valid faces)

plane normals MUST be normalised. no exceptions.
the normal says the direction the plane is facing, the distance says how far along the plane is along that normal from the origin.
That is, the point at (planedist*planenormal) sits on the plane. Alternatively, planedist=dot(pointonplane,planenormal);

(note that dot(x,y) === x*y in qc, but I'm using function notation because x*y is somewhat weird when you have floats in one place and vectors in another)

so if you want an axial cube centered on the origin, use normals of +x, +y, +z, -x, -y, -z (and by +x I mean '1 0 0'), and some distance that says the 'radius' of the box. to then move it by some vector, planedist += dot(translation,planenormal); should be applied to each of the 6 planes (this logic works regardless of any rotation you have applied. note that using makevectors and negating the results for the other 3 planes should be enough to create a rotated cube centered around the origin).
note that the translation thing can be applied to a single plane, which gives you the translation of a single plane / surface. and by translation, I of course mean 'move' (or the vector/displacement for that movement).

the sdir/sbias and tdir/tbias fields are essentially the same as the plane planenormal/planedist, except that they apply to the texture coords instead. the dir vectors do not need to be normalised, which allows for rescaling the texture. they should normally be tangenital to the normal and each other - that is that the 3 normals each face 90 degrees from each other in order to avoid skewing.
by changing the bias values the same way when translating, you will obtain texture lock.

note that out_x = dot(v_forward,in); out_y = -dot(v_right,in); out_z = dot(v_up,in); can be used to rotate a plane normal (first call makevectors with the rotation difference as an argument - note targ-src angle, which is sucky to calculate with eular angles so try to avoid absolute angle values). adjusting the distance is more tricky, effectively you need to translate the rotation pivot to '0 0 0', rotate it, then move it back.

is it a bird? is it a plane? no, its a friggin maths equation. gah.
with the right helper functions, you should find it managable enough.

[toneddu2000]

Thanks Spike, your help is always very precious. Right now I can't understand how to create the origin between two brush faces but I'll make some tests and I'll post them here (or releasing directly crafter release with brush support inside, but more probable that I'll make only some tests). Right now scene is empty but let's see what I can do with a couple of day of 3d math full immersion!

[Julius]

Some random ideas:
- A vegetation model placement brush on terrain would be cool
- A sort of random dungeon generator, or at least a quick placement option of walls, corners etc. would be nice.

Anyways, really looking forward to the progress you make.

[toneddu2000]

- vegetation "brush" system is on the todo list
- random dungeon generation: no, I don't think of any good reason to put it into an editor. Usually it would be more useful as script imo, to be used dynamically in code

[toneddu2000]

Ehm, Spike, could you please post a simple code that creates a cube via brush_create? I tried and tried but no clues about orienting faces and set distance between them.

[Spike]

[toneddu2000]

[Spike]

it takes a pointer, eg either tmp_faces or &tmp_faces[0] (they're meant to be equivelent). I just thought I'd make it more clear that it was a pointer.

qc assumes all numbers are floats. so eg 6 is a float, that needs to be converted to an int if its stored into an int variable. this normally happens automatically of course (and for free if its an immediate), but there's a few ways that the variable is taken verbatim where automatic conversions cannot take place (like __variant function args), plus there's type promotions so eg 3i/2i is 1i, while 3/2i is 1.5, where its especially important is to use ints to avoid precision loss from bitwise operations on floats.
so it can be nice to be explicit about it, even if its not technically needed.

[toneddu2000]

understood. Thanks for the explanation

[Julius]

Any news on a possible alpha release of this?

[toneddu2000]

Yeah, you're right Julius. I've been completely busy with work/study that I leave Crafter as a draft. I should have at least released a first stub with a handful of models...Let's see next week-end what I can do.

Keep in mind that it's junk. Don't think to thow NetRadiant or whatever to garbage and start using Crafter because it's not still usable and probably it will never be. I don't have the skills to create a level editor and probably quakec is not the best language to do it. But, but, if Spike should consider the idea valid and re-translate the code (with all the modifications he thinks it needs) to full C code, well.. then it could be interesting! I'm just toying with terrain and brush editing. Once drafted a little that could be the time for a first alpha or whatever

One thing is clear right now (and I say it without any kind of presumption): in 2017 there's no space anymore for x-radiant + qxmapwhatever stuff. With Unity and Ue4 being the perfect concept of "live level editor", Crafter *could* be the logical transposition to FTE universe.. with a lot of "if" as prefix..

[Julius]

No worries, I am not expecting to toss out a full level editor for it (but I am hoping to replace Radiant with Trenchbroom soon).

I see it more as a start for something like Snap Map from the latest Doom release, i.e. something to play around assembling ready made parts. Optimizing realtime lights and bot nodes etc icould also be a cool use for it.

Anyways, looking forward to the alpha release!

[toneddu2000]

[Julius]

Oh yeah, an alpha release from projectUnkown would be great of course too!