[FTEQW][WIP] craFTEr - realtime game editor for FTE
Posted: Fri Dec 23, 2016 4:48 pm
Project has been completely rewritten from the ground up. This description no longer fits.
Release date: tba
Release date: tba
I created a new UI library from scratch (already embedded in Crafter) that makes UI creation a breeeze! You can create sliders, buttons and windows in no time! Probably I'll release as separate "pack" before Crafter releaseSpike wrote: (I hate writing UIs).
Yeah, in first version there was mesh preview, but then I added UI slider component and I had no time to re-arrange the code to show it in slider, but it's a matter of 3/4 hours of work.Spike wrote:(also, needs model previews!)
Ok, no prob, editor already defines a maximum grid size. I'll use it for both grid and terrainhowever you first need to define the maximum size of the terrain as worldspawn keys, and use the 'mod_terrain_save' console command to save it to disk.
mmm..didn't know that. Thanksregarding pointers the easiest way to deal with them is to just define some global arrays and pass those into the brush builtins as needed. then you can just index the arrays without resorting to allocating/freeing/etc pointers.
So there's no easy way to retrieve singular vertex position?Vertex manipulation is much more challenging. My aproach was to just decompose the brush into polygons and then reform the brush according to the modified polies. any concavities result in cutting into the rest of the brush, these should be obvious in the previews that I added.
yeah, I'm not a fond of brushes, I could use them for collisions hulls, anyway, which it's cool, because designers could draw simple collision hulls around their super-complex models and with a little of tracebox (which, I must say, it doesn't work as I thought. It's a real pain in the XXX to reset trace_fraction after a if(trace_fraction < blah) code block)but yes, terrain+meshes+entities should be enough for most things if you're going for an open-world kind of feel. You can even embed non-sealed BSPs too if you need more complex geometry made with eg trenchbroom.
terrain_edit(TEREDIT_TEX_BLEND, trace_endpos, radius, percentage/100.0, "yourtexturehere");toneddu2000 wrote:Terrain) Does it work terrain texture now? Because I remember that some time ago it wasn't possible to add diffuse texture
yes and no.But, are brushes rendered via GPU? Because I noticed that R_BeginPolygon stuff completely destroys fps when I load model of 3000 triangles. Working technically inside CSQC_UpdateView, I thought it was rendered by GPU, but looking at framerates, it seems more rendered by CPU
you can get a list of verts from an engine-held brush with the brush_getfacepoints function. call it once per face (if you only give it space for 1 point it'll return the midpoint of the brush, 2 points gives the bounding box).So there's no easy way to retrieve singular vertex position?
brushes are useful because they provide well-defined volumes like water or solid areas that cannot be seen through. they will always perform best when pre-compiled...yeah, I'm not a fond of brushes, I could use them for collisions hulls, anyway, which it's cool, because designers could draw simple collision hulls around their super-complex models and with a little of tracebox (which, I must say, it doesn't work as I thought. It's a real pain in the XXX to reset trace_fraction after a if(trace_fraction < blah) code block)
ok, thanksSpike wrote:terrain_edit(TEREDIT_TEX_BLEND, trace_endpos, radius, percentage/100.0, "yourtexturehere");
Ok understood. But I think that, even without culling, on a modern machine, it should be ok to draw hundreds of boxes made by 12 triangles each.Spike wrote:brushes held by the engine are rendered via the gpu, but there's no culling. the engine will just batch up a whole load of brushes ito a single vbo and draw that, so it should be fast enough despite the exterior etc of brushes being drawn. however there's no culling for rtlights and shadows etc right now either
Yeah, the problem is that it's not possible to set a maximum of rendering-times-per-frame. You know what? That could be cool to add a .float after .predraw call for every drawing entity that cap the rendering-per-frame to that variable. Of course using R_BeginPolygon to draw polygons on the fly is not what I need for, but sometimes it's quite a priceless feature. For example, in the editor, grid drawing is made by R_BeginPolygon calls, and, when grid is very dense (like 32 units or 16 units) framerate falls from 500fps to 200fps when nothing is on the screen except grid linesSpike wrote: R_BeginPolygon will always be slow if you're calling it 3000 times per frame. most of that is just qc overhead... either way it lacks normals/tangents/bitangents, so it isn't advised to draw models with it even if it was just as fast.
yeah, I'll use this second one, because every brush created are created in qc, no brushes created by radiant. ThanksSpike wrote:alternatively if your qc has a list of planes then you can call brush_calcfacepoints with a similar result.
You're right. I could also use brushes for water/lava pools or for portal/antiportals entity, to reduce useless drawing calls. Of course, for second one, I'll need your help to let engine knows how to decide (maybe with a shader?) that brushes with portal/antiportal "tag" need to be excluded by renderingSpike wrote:brushes are useful because they provide well-defined volumes like water or solid areas that cannot be seen through. they will always perform best when pre-compiled...
Are you talking about release r5033 modification where you say "fix hitmodel with skeletal models(can also now support lerps, skeletal objects, etc)."?Spike wrote:I have made a couple of steps towards separate render/collision meshes inside iqms, but there's still a few other things that I want to change to make the format more interesting.
Thanks frag.machine, my goal is to create a usable (and this is not easy task, not easy at all) tool to permit level designers to create games without coding, accessing a huge collection of open source models and a library of pre-defined behaviours, so, probably is more like SnapMap, but with the possibility to choose which game type to run (fps, tps, racing game, point&click adventure,etc.), but, of course, this is just a dream, not possible to do all these features in my spare time. I want to release as soon as possible a STABLE entities placing tool. That's the immediate plan. After that I need to learn FTE_multiprogs part and release it as an "API" (like csaddon). So you download "crafter.dat" (for example), put it on your data folder, create your levels, save them in a format I need to still think abiut it and then delete the .dat when you gonna release the gamefrag.machine wrote:Nice work, tonneddu. Are you aiming something like DOOM's Snapmap or more a GarryMod level of freedom ?
Aye, you can play all the id maps without any issues. Side note: deleting whichever brushes monsters are standing on can be quite fun...toneddu2000 wrote:But I think that, even without culling, on a modern machine, it should be ok to draw hundreds of boxes made by 12 triangles each.
something that caps on an individual frame basis would result in flickering. if you want something that takes a few frames to kick in, then just fade anything according to distance and framerate. drop the distance if the load is too high, increase if its high enough.Yeah, the problem is that it's not possible to set a maximum of rendering-times-per-frame. You know what? That could be cool to add a .float after .predraw call for every drawing entity that cap the rendering-per-frame to that variable.
There was meant to be some extension for the engine to directly accept trisoup (or linesoup), but I think its still too buggy to advertise.Of course using R_BeginPolygon to draw polygons on the fly is not what I need for, but sometimes it's quite a priceless feature. For example, in the editor, grid drawing is made by R_BeginPolygon calls, and, when grid is very dense (like 32 units or 16 units) framerate falls from 500fps to 200fps when nothing is on the screen except grid lines
You're thinking about that wrongly.yeah, I'll use this second one, because every brush created are created in qc, no brushes created by radiant. ThanksSpike wrote:alternatively if your qc has a list of planes then you can call brush_calcfacepoints with a similar result.
The current changes just fix bugs. I plan on creating an extension for iqms with support for content masks. Set your visible mesh as non-solid and your collision mesh as contents_body or something, and traces will then only need to collide against the collision mesh. Also needs some toolchain tweaks for people who are too lazy to make actual meshes (ie: hitboxes that follow bones ala halflife, but that's just a hitmesh-generation tweak for lazy people).Are you talking about release r5033 modification where you say "fix hitmodel with skeletal models(can also now support lerps, skeletal objects, etc)."?Spike wrote:I have made a couple of steps towards separate render/collision meshes inside iqms, but there's still a few other things that I want to change to make the format more interesting.
Could you tell us mor about it? Because I'm very interested. Also about new feature that will make format more interesting, of course
mmm... interesting concept for a one-day mod...Spike wrote: Side note: deleting whichever brushes monsters are standing on can be quite fun...
Not quite sure what do you mean by "distance" but I get half of the concept, so I'll make some testsSpike wrote: something that caps on an individual frame basis would result in flickering. if you want something that takes a few frames to kick in, then just fade anything according to distance and framerate. drop the distance if the load is too high, increase if its high enough.
yeah, that could be an option too. Dunno why but I didn't take in consideration GLSL. ThanksSpike wrote:There are other ways to draw a grid, like using glsl on a single quad to tint pixels close to the boundaries.
This is BIG note, not small! Thanks, very helpfulSpike wrote:small note: if you do happen to be drawing 500 primitives, in fte you can omit the begin calls between primitives. begin();verts1();end();verts2();end(); the result is a small reduction in overheads as the engine can then skip shader lookups etc.
Ok, I get it now. Thanks!Spike wrote:You're thinking about that wrongly.
The ideal is for mods to use the brush_create function - the brushes come from the qc code, but they're given and then 'owned' by the engine (until the qc deletes that brush, anyway). This means that the engine knows that the brush is going to be long-lived, and can build it into static batches. brushes defined as qc plane lists are really only meant to be a short-term thing, because doing anything with them is subject to overheads (like recalculating the verticies each time its called).
W..ow.. if you add this, I'll try to create ragdolls in editor, directly with qc, no ODE s**t anymore! Imagine also physically-based behaviour like limb recoil on shot, etc.Spike wrote:The current changes just fix bugs. I plan on creating an extension for iqms with support for content masks. Set your visible mesh as non-solid and your collision mesh as contents_body or something, and traces will then only need to collide against the collision mesh. Also needs some toolchain tweaks for people who are too lazy to make actual meshes (ie: hitboxes that follow bones ala halflife, but that's just a hitmesh-generation tweak for lazy people).
Thanks Julius for your interest in Crafter! It think it's doable but I never used Sketch Up so I don't know which kind of visual guidelines I could add. Do you have any suggestion? The idea of adding "snapping helpers" is quite cool, I must sayJulius wrote: Looks really awesome!
Would it be possible to have some Sketchup like guidelines and other helpful tools to make placement of objects in 3D space a bit easier?
Not sure what you're talking about, sorry. UI library is only 2d because UI in general is 2d! Even crysis or DOOM hud which seem distorted by perspective but are 2d nonetheless. If you're instead talking about 3d models with UIs unwrapped on top of them, well, I *GUESS* it could be possible but I'm quite not sure how (probably with project() calculations..)For the UI kit (and the editor): please do not make it 2D only, but with the possibility to render it in 3D space. That way it would be still use-able in VR as prototype WebVR support has been recently added to FTEQW and editing maps in 3D with a controller like the one that comes with Google Daydream is probably pretty cool.