Forum

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

The home for dedicated threads to specific projects, be they mods, tools, or independent games.

Moderator: InsideQC Admins

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

Postby toneddu2000 » Fri Dec 23, 2016 4:48 pm

Project has been completely rewritten from the ground up. This description no longer fits.
Release date: tba
Last edited by toneddu2000 on Sat Nov 25, 2017 3:52 pm, edited 3 times in total.
toneddu2000
 
Posts: 1308
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby Spike » Fri Dec 23, 2016 5:53 pm

you should probably consider grabbing either the terrain or brush editor parts of csaddon, then give them all the polish that I've so far failed to give them (I hate writing UIs).
(also, needs model previews!)
Spike
 
Posts: 2882
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby toneddu2000 » Sat Dec 24, 2016 9:47 am

Yeah, I should. There are basically two problems:
  1. Your code is real code, so, sometimes is very difficult for me, as newbie, to understand it. Probably I'll need some help, like always. I took a look at csdefs for brush api and it requires * pointers as brush faces arguments. I tried to create a pointer but it crashed csqc.Regarding terrains, I never even took a look at csaddon code, so I dunno if my poor skills can manage it.
  2. License could be an issue. I created everything (code, models and textures) to be released as CC0. This is very important to me, because I want that devs or artists can use any piece of the Crafter "container" as they want, with no restrictions. Are you ok to convert some part of csaddon to that license? There are blocks of code derived from other project (and so with other license)?

Spike wrote: (I hate writing UIs).
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 release
Spike wrote:(also, needs model previews!)
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.
toneddu2000
 
Posts: 1308
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby Spike » Sat Dec 24, 2016 4:51 pm

terrain is fairly straight forward, you can just call a builtin to raise or lower the terrain around some point, with a radius parameter and stuff. painting textures is basically the same with an added width. you shouldn't really need csaddon's terrain code for anything other than documentation.
however 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.

brush editing is much more convoluted, yes.
regarding 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.
from the engine side its somewhat straight forward. the [cs|ss]qc can get a list of brushes within a bbox, it can query a list of planes from each brush, it can delete brushes, it can create brushes (any redundant planes are ignored). there's also a utility function or two that can calculate the winding[read: polygon/trifan] of a face from a brush/plane-list.
the qc is then responsible for modifying the plane lists of each brush. to split a brush just clone it and insert a plane into the original and the copy, with the plane being mirrored. when you then delete the original and create your two copies the engine will disregard any redundant planes and you end up with two neighbouring brushes.
but yeah, at the end of the day, the qc just sees lists of planes. each plane has two texture 'planes', so you can just treat each plane as a 4*3 matrix. to move/rotate/whatever a brush, just transform those matricies - yay dotproducts. My code should contain an example of this for rotation/moving/etc, but you'd want to give it a decent UI.
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.

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.
including brush editor stuff is more for completeness.
Spike
 
Posts: 2882
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby toneddu2000 » Sat Dec 24, 2016 8:06 pm

Thanks Spike for the detailed answer

Terrain) Does it work terrain texture now? Because I remember that some time ago it wasn't possible to add diffuse texture
however 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.
Ok, no prob, editor already defines a maximum grid size. I'll use it for both grid and terrain

Brushes)
regarding 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.
mmm..didn't know that. Thanks

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

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.
So there's no easy way to retrieve singular vertex position?

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.
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)
toneddu2000
 
Posts: 1308
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby frag.machine » Sun Dec 25, 2016 12:31 am

Nice work, tonneddu. Are you aiming something like DOOM's Snapmap or more a GarryMod level of freedom ?
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
User avatar
frag.machine
 
Posts: 2068
Joined: Sat Nov 25, 2006 1:49 pm

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby Spike » Sun Dec 25, 2016 7:08 am

toneddu2000 wrote:Terrain) Does it work terrain texture now? Because I remember that some time ago it wasn't possible to add diffuse texture

terrain_edit(TEREDIT_TEX_BLEND, trace_endpos, radius, percentage/100.0, "yourtexturehere");


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

yes and no.
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, which can make them slower than they otherwise should be. traces are more expensive that q1bsp too, mostly because there's no bsp tree to optimise things. also the engine will run a cpu lighting algorithm on newly-modified surfaces much like light.exe (but with no shadows, because of that traceline issue).
brushes defined by the qc are going to be slow to draw. this shouldn't be an issue if the qc isn't trying to draw an entire map.
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.


So there's no easy way to retrieve singular vertex position?

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).
alternatively if your qc has a list of planes then you can call brush_calcfacepoints with a similar result.

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)

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...
I don't get what you mean by resetting trace_fraction, but in other news 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.
Spike
 
Posts: 2882
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby toneddu2000 » Sun Dec 25, 2016 10:23 am

Spike wrote:terrain_edit(TEREDIT_TEX_BLEND, trace_endpos, radius, percentage/100.0, "yourtexturehere");
ok, thanks

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
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: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, 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 lines

Spike wrote:alternatively if your qc has a list of planes then you can call brush_calcfacepoints with a similar result.
yeah, I'll use this second one, because every brush created are created in qc, no brushes created by radiant. Thanks

Spike 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...
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 rendering

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.
Are you talking about release r5033 modification where you say "fix hitmodel with skeletal models(can also now support lerps, skeletal objects, etc)."?
Could you tell us mor about it? Because I'm very interested. Also about new feature that will make format more interesting, of course

frag.machine wrote:Nice work, tonneddu. Are you aiming something like DOOM's Snapmap or more a GarryMod level of freedom ?
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 game
toneddu2000
 
Posts: 1308
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby Spike » Sun Dec 25, 2016 10:52 am

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.
Aye, you can play all the id maps without any issues. Side note: deleting whichever brushes monsters are standing on can be quite fun...

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.

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.

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

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.
There are other ways to draw a grid, like using glsl on a single quad to tint pixels close to the boundaries. Yes, drawing arbitrary polygons is useful, but try not to go crazy with them because there's generally(though not always) a better way.
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.

Spike wrote:alternatively if your qc has a list of planes then you can call brush_calcfacepoints with a similar result.
yeah, I'll use this second one, because every brush created are created in qc, no brushes created by radiant. Thanks

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).

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.
Are you talking about release r5033 modification where you say "fix hitmodel with skeletal models(can also now support lerps, skeletal objects, etc)."?
Could you tell us mor about it? Because I'm very interested. Also about new feature that will make format more interesting, of course

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).
Spike
 
Posts: 2882
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby Julius » Sun Dec 25, 2016 7:19 pm

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?

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.
Julius
 
Posts: 91
Joined: Sun Aug 29, 2010 4:32 pm

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby toneddu2000 » Mon Dec 26, 2016 3:55 pm

Spike wrote: Side note: deleting whichever brushes monsters are standing on can be quite fun...
mmm... interesting concept for a one-day mod... :biggrin:

Spike 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.
Not quite sure what do you mean by "distance" but I get half of the concept, so I'll make some tests

Spike wrote:There are other ways to draw a grid, like using glsl on a single quad to tint pixels close to the boundaries.
yeah, that could be an option too. Dunno why but I didn't take in consideration GLSL. Thanks

Spike 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.
This is BIG note, not small! Thanks, very helpful

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).
Ok, I get it now. Thanks!

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).

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.
That would be so AWESOME.

Julius 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?
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 say

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.
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..)
toneddu2000
 
Posts: 1308
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby ceriux » Wed Dec 28, 2016 2:53 am

Very cool , wish I were as intelligent as some of you guys. :D
User avatar
ceriux
 
Posts: 2223
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby toneddu2000 » Wed Dec 28, 2016 9:05 am

Thanks ceriux, but I can't consider myself quite intelligent nor skilled(and once I'll release code you'll see why), but my only value is that I'm stubborn like a mule! :biggrin:
toneddu2000
 
Posts: 1308
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [FTEQW][WIP] Crafter - realtime game editor for FTE

Postby frag.machine » Wed Dec 28, 2016 11:25 am

Well talent and intelligence alone won't accomplish nothing. A little stubbornness and good ammount of hard work are essential to turn these qualities in great results. Keep the good work going on!
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
User avatar
frag.machine
 
Posts: 2068
Joined: Sat Nov 25, 2006 1:49 pm


Next

Return to Project Showcase

Who is online

Users browsing this forum: No registered users and 1 guest