I'm wondering if we could create MAP files within Blender via python scripting.
I've started coding the initial code of the scripts, I'm using this as a reference for the map format: https://modwiki.xnet.fi/MAP_%28file_format%29
how could then the UV coords for the materials be applied? it woudl be great to have the UV pre-established as in any radiant
how would entities be set? maybe create a box and have it a "custom property" announcing it's "spawnclass"?
on the bezier surfaces (patches) blender has a bezier very similar to idtech3/4
well guys what do you think?
Blender 2.49 already has a .map exporter. I don't know if it's compatible with D3 but it does work with Q2/3. That would be a good start to see how they did that one.
do you have it? I've been trying to locate the most recent version of it, it should have been in a more modern Blender, but in the current version of Blender it's no longer present in the addons folder.
Here's the Blender 2.49b release downloads: http://download.blender.org/release/Blender2.49b/
Just download the one for your OS & install/unzip. The script has some issues, like not settings verts to the grid all the time, everything is walls (no solid brushes), but it works.
I've been toying with it, and I see that even the most recent version of that script is for quake 1 / 2 map system
quake 3 used version 2 already that stores the brush info diferently, it stores the brush face with the "face equation" and then a 3X2 matrix for the textures in this implementation:
(plane equation) ( ( xxscale xyscale xoffset ) ( yxscale yyscale yoffset ) ) "material" ?
where the plane equation is 4 numbers: 3 for normal direction and the fourth for the shortest distance to the center of the map
therefore a brush is a mesh defined not by its vertex positions but by the volume inside it's faces
so that means that the "quake map" script is useless
I've been working on a new .map format for id Tech 4 for the last weeks. I have an implementation on my private branch that works with polygons instead of brushes like Blender works.
I also modified the map compiler and the collision framework to support it. AAS support is still missing but I think I can figure out that as well.
I was able to build a valid BSP tree using triangles instead of brushes once I figured that dmap bsp surfaces only require windings and not brush sides.
I'm going to merge this back to RBDOOM-3-BFG this or the next weekend. It would be cool if I can get some support in the Blender scripting department.
My plan is to scrap the Radiant level editors completely and the first big important step is done. I thought it would be trivial but it took me another 80 hours to get it done with areaportals and everything.
My branch also features nice .map -> .obj exporters and dmap features -glview that exports several .obj files for BSP / split plane analysis in Blender.
https://www.dropbox.com/s/6vmw0dwlyebih6j/Screenshot%202015-02-23%2014.33.29.png?dl=0
https://www.dropbox.com/s/lewlkqcnduz4qf3/Screenshot%202015-03-11%2000.26.53.png?dl=0
The effort is admirable, but getting a rid of brush based level design workflow is not wise. Even UE4 will be bringing CSG/BSP geometry back. Rapid prototyping is not possible with models.
AFAIK ETQW made it possible for AAS to use models too, which I think is a way to go. But hey, anyone can do whatever they want with their engines :-) Good luck trebor.
Trebor this is great news! I was thinking on adding a new brush token that used definitions for triangles instead of planes, I also think we should maintain the brush system though, because it makes prototyping a level quite easy.
I also think removing BSP geometry is not wise, for whats its worth, like others said prototyping is faster, is also easier for a younger modder to mod your game, learning Radiant like tools is easier than learning blender or any other alike 3D app. Is also faster to make your map and see it ingame.
Valve didn't removed BSP they even used it has a template for their terrain system on Source, Epic didn't removed it even on UE 4 (even tho i found its BSP tools to be inferior to Radiant), Cryengine and Unity have tools on the editors that give us the ability to box map (not really BSP).
I've found the method by which find the distance between the surface and the origin of the map (the fourth number in the brush surface equation):
Find the tangent to the surface. Then find the equation of line perpendicular to the tangent. Substitute the points. You will get the equation of line. Find its intersection with the surface(points). Then find the distance between two points.
now i need to translate this to python and to idtech4 specifics...
Quote from: BielBdeLuna on March 27, 2015, 12:51:16 AM
now i need to translate this to python and to idtech4 specifics...
May I ask why do you need this? If you want to make a .map file in blender and then finish it in Radiant (any flavor that works with Doom 3) then it makes no sense, sorry.
If you need some ideas to put your unending energy into a more practical direction, I have a few :-) Solving "player gets stuck" beyond 32k units around 0 0 0 of the map is one of them. Besides the obvious solutions, there is an unfinished function in physics_player.CPP that suppose to get player unstuck. That would be a really useful fix that would help all :-)
My approach is just the next logical consequence because I don't want to maintain any crappy radiant editor and this stuff is to enhance my own productivity on the content production side.
And it only requires a new meshDef primitive definition in the .map file. You can forget to export Blender polygons to brush sides because it has tons of limitations and is error prone.
It is also obsolete because brushes are converted to windings which are equivalent to Blender N-Gons anyway. So it is better to write a .map file that contains meshes with N-Gon faces.
Quote from: trebor on March 27, 2015, 09:02:03 AM
My approach is just the next logical consequence because I don't want to maintain any crappy radiant editor and this stuff is to enhance my own productivity on the content production side.
And it only requires a new meshDef primitive definition in the .map file. You can forget to export Blender polygons to brush sides because it has tons of limitations and is error prone.
It is also obsolete because brushes are converted to windings which are equivalent to Blender N-Gons anyway. So it is better to write a .map file that contains meshes with N-Gon faces.
Although you already settled with new approach, may I ask if you tried DarkRadiant? (I know it's not a flexible as Blender, but it seems to be the best of Radiants for Doom 3 out there).
- dark radiant doesn't compile form me since several builds
- dark radiant displays strange geometry in the compiled builds due some kind of incompatibility between the intel GPU I have and the new framework they are using
- my time is for me to waste on whatever I want to waste it to, is what you waste your time worth the time you waste on it?
besides I get a great hardon when I solve maths problems by myself and my findings, and that REALLY suits me... is it ok? do you approve? ;D
Trebor how do you need data structured in your implementation?
Quote from: BielBdeLuna on March 27, 2015, 11:26:12 AM
besides I get a great hardon when I solve maths problems by myself and my findings, and that REALLY suits me... is it ok? do you approve? ;D
Oh, then you will definitely a get double (or even triple) of that by solving collision issues :)
I see your reasons for using Blender (I have similar concerns, but not really due to the same issue you have) as mapping tool.
The fundamental issue of using Blender for mapping (and exporting to .map) isn't the brushes. We already have exporter that sames .map with perfect brush work (Quake 3 .map) and making it saving Doom 3 brushes isn't that hard. The core issue is texturing these brushes, since not only there is no UV map on them, but there are no tools to do texturing in Blender like it's done in Radiant (and exporting proper texture coordinates). Another issue is lights, entities, links and bindings, etc.
there are no texture tools in dark radiant like there are in Blender!
quake/d3 texture all derive form the centre of the map, there is no secret there, it's all planar projections on the surfaces that conform the brushes.
that's the sole reason there is no UV projections (because there aren't any vertex positions to start with) there is only translation rotation and scale all deriving from the centre of the map.
as you see the centre of the map does play a greater role than just being the origin of the world coordinates.
Quote from: BielBdeLuna on March 27, 2015, 12:00:57 PM
there are no texture tools in dark radiant like there are in Blender!
quake/d3 texture all derive form the centre of the map, there is no secret there, it's all planar projections on the surfaces that conform the brushes.
that's the sole reason there is no UV projections (because there aren't any vertex positions to start with) there is only translation rotation and scale all deriving from the centre of the map.
as you see the centre of the map does play a greater role than just being the origin of the world coordinates.
What I am saying is in Radiant, you slap material on the face of the brush, and slide/scale it, or select several faces on several brush and press a button to align the materials. It's extremely fast workflow and Blender is incapable of providing such workflow. Not to mention you can't select several meshes in Blender and edit them all at once to match UV maps. UV mapping is the slowest workflow for architectural modeling. Not to mention as soon as you edit mesh that you already UV mapped, it will screw up existing UV map. And I am telling this because of my experience working with CSG and modeling.
Blender would need an add-on that does all the texture mapping under the hood, where the workflow/UI if the same as in Radiant for brushes.
Hey, but who am I to be listened to. Export Doom 3 map as OBJ, remove all the texture coordinates, turn it into a mesh as if it was modeled in Blender initially and try texturing it. You'll quickly see what I am talking about ;)
I bet its far easier than not seeing your closer walls in front of your further walls in order to texture as it is for me at the moment within Darkradiant, go figure ;)
but let's be constructive for a change, eh... motorsep? I guess we could use a fake object in the middle and reference this object as a texture guide (as for a centre) and then add special properties at the objects in order to change it's UV mapping in relation to that object, this could be done in a one click operation and sort of automatically via python. so it would apply UV mapping to all selected "brushes-meshes" and create their UV mapping taking into account several special properties
there though other problems how do we know what materials there are available? and the entities? could we decode the resource files automatically via python and gather all this info? could we get pk4 support? etc...
but first things first I'm trying to sort out the plane equation and so let some first code to the future repository so all can try: https://github.com/BielBdeLuna/Blender_IDtech4_GPL_map (https://github.com/BielBdeLuna/Blender_IDtech4_GPL_map)
The closest thing you can do is to use generated texture coordinates with planar mapping. Maybe new box mapping could work. The problem is that Blender can't, at its core, work with several selected objects at once. It can only work with one object at a time.
You can make add-on to create dynamic dialog and populate it with properties from .def files. Basically you'd recreate DarkRadiant in Python for Blender. I don't know if you can do that straight from .resources. Perhaps you can write IO for that in Python, but that might not be supported in Blender's API.
ok I will ask you to stop giving me your support at the moment, I really don't need it right at the moment.
Quote from: BielBdeLuna on March 27, 2015, 04:05:28 PM
there though other problems how do we know what materials there are available? and the entities? could we decode the resource files automatically via python and gather all this info? could we get pk4 support? etc...
My plan was to write an "exportEntityDefinitions" console command that iterates through all entity and model declarations in def/* and exports its into a single xml file for the blender plugin.
ok sounds great :)
that's my current plan for the exporter no code yet, and just for exporting brushes:
- make a list of selected objects in the scene
- if there aren't selected obejcts in the scene gather them all in the list
- check if all their faces are coplanar?
- error if non complanar faces?
- for every object
- for every coplanar quad face
- gather normal
- find the shortest distance between the surface, in which the face is inscribed in, and the global centre
- figure out how to translate the UVmap to a global UV mapping
- write brush info in the *.map file
- get a solution for non coplanar quad faces?
- separate the two tris as if they where two different surfaces?
- i think non coplanar quad faces are not allowed in radiant
- are concave/convex surfaces a problem?
I've coded a mock-up UI in blender in order to have something working, and I've pushed the changes to Github (https://github.com/BielBdeLuna/Blender_IDtech4_GPL_map), I'm calling it "Export idTech GPL map" which I don't quite like, it follows the "Export Quake map", and the "Export idTech4 model" script names scheme, so it fits but it's not that much of a differentiation as idtech 2 and 3 are also GPL, and I don't quite like calling it "idTech4.5", how would you guys call a engine derived from the BFG gpl release?
I would like to propose "idTechX" because, X could be a variable meaning any number, and also because X in Roman numerals means 10 which in number is far superior to the already released idTech 2-4, so it's something else besides those engines
I'm stuck! I have the code calculating the normal, which was a super easy function in Blender
After using a much difficult function, and complicating me the existence, I've found now an easier function that calculates the distance between a point and a surface, it only needs the point, the normal of the surface and a point on the surface the normal and the point (which is one of the vertices of the polygon that resides in the surface) are the only thing needed to represent the surface
Blender doesn't accept that function and it returns an error TypeError: distance_point_to_plane which seems like I'm mismatching the variable type to store the return of distance_point_to_surface function, but the variable is initiated by the function (which returns a float, which is what I need) so... I don't know. I guess now it's time to sleep and tomorrow I'll find the damn solution
after that I'll skip the brushDef3 texture as it seems to be something damn difficult and I'll try to export the vertices of a spline.
texture info in brushDef3 seems like a way too complicated scheme, I can image a simpler way to store the same texture info, which could uses a number less. but I guess every complication has it's reasons, so time will tell, let's all learn from those complications. O0
As always the code is in github: https://github.com/BielBdeLuna/Blender_IDtech4_GPL_map (https://github.com/BielBdeLuna/Blender_IDtech4_GPL_map) so if you want to check it out you're free to do so. :D
at least I got it to export several brushDef3 objects, albeit too small, now I'll try to add the scale back
but normal is done and
distance is done
wait, distance it's not right >:(
done, it works now,
so I'm now at 0.0.1 alpha stage, I can export tiny brushDef3 brushes with fake texture coordinates and a strange material
it's tiny because it's lacking the scale conversion yet but it's there. :D
I uploaded my changes of my new .map file format primitive.
https://github.com/RobertBeckebans/RBDOOM-3-BFG/tree/map-primitive-polygons-for-blender
You can convert existing maps using
convertMap <mapname> and it will write a _converted.map version.
Then you can compile it with dmap. AAS support is still missing.
Common_mapconvert.map also features an OBJ map exporter.
You can use it with the exportMaptoOBJ <map> console command.
This way you don't have to mess with brushes or curves anymore. Simply model everything in your map in blender and put it into a BSP group.
Export the BSP group as worldspawn and everything else as indiviual entities. Then it should work.
The map format still needs to be extended. The new mesh primitives should be flagged as detail geometry or non detail geometry.
Because you don't want to have pipes and other curves considered as structural BSP geometry.
This is how it looks
// entity 0
{
"classname" "worldspawn"
// primitive 0
{
meshDef
{
( 24 6 0 0 0 )
(
( 192 -128 256 -2 -2.998046875 0.003921628 0.003921628 -1 )
( -192 -128 256 -2 3 0.003921628 0.003921628 -1 )
( -192 256 256 4 3 0.003921628 0.003921628 -1 )
( 192 256 256 4 -2.998046875 0.003921628 0.003921628 -1 )
( -192 256 272 4 -2.998046875 0.003921628 0.003921628 1 )
( -192 -128 272 -2 -2.998046875 0.003921628 0.003921628 1 )
( 192 -128 272 -2 3 0.003921628 0.003921628 1 )
( 192 256 272 4 3 0.003921628 0.003921628 1 )
( -192 256 256 -4 -4 -1 0.003921628 0.003921628 )
( -192 -128 256 1.9990234375 -4 -1 0.003921628 0.003921628 )
( -192 -128 272 1.9990234375 -4.25 -1 0.003921628 0.003921628 )
( -192 256 272 -4 -4.25 -1 0.003921628 0.003921628 )
( -192 -128 256 -3 -4 0.003921628 -1 0.003921628 )
( 192 -128 256 3 -4 0.003921628 -1 0.003921628 )
( 192 -128 272 3 -4.25 0.003921628 -1 0.003921628 )
( -192 -128 272 -3 -4.25 0.003921628 -1 0.003921628 )
( 192 -128 256 -2 -4 1 0.003921628 0.003921628 )
( 192 256 256 4 -4 1 0.003921628 0.003921628 )
( 192 256 272 4 -4.25 1 0.003921628 0.003921628 )
( 192 -128 272 -2 -4.25 1 0.003921628 0.003921628 )
( 192 256 256 -3 -4 0.003921628 1 0.003921628 )
( -192 256 256 2.998046875 -4 0.003921628 1 0.003921628 )
( -192 256 272 2.998046875 -4.25 0.003921628 1 0.003921628 )
( 192 256 272 -3 -4.25 0.003921628 1 0.003921628 )
)
(
"textures/base_wall/lfwall27d" 4 = 3 2 1 0
"textures/base_wall/lfwall27d" 4 = 7 6 5 4
"textures/base_wall/lfwall27d" 4 = 11 10 9 8
"textures/base_wall/lfwall27d" 4 = 15 14 13 12
"textures/base_wall/lfwall27d" 4 = 19 18 17 16
"textures/base_wall/lfwall27d" 4 = 23 22 21 20
)
}
}
First you have a list of position x y z then texcoords and then the normal. Later you define the faces or polygons which can have more than 3 or 4 vertices.
So this is Blender N-Gon compatible.
that's great!
let me see:
QuotemeshDef are:
- a group of numbers that are unknown to me at the moment
- followed by the data per vertex
- followed by the data per face
in the following form:
meshDef
{
( num num num num num ) //5 numbers, what is this first row of numbers?
(
( num num num num num num num num ) //8 numbers, posX, posY, posZ, posU, posV ,normalX, nomalY, normalZ
* amount of vertices
)
(
"idMat" 4 = num num num num // what is the "4"? and the next four numbers? are those the vertex index that conform the face? is the "4" indicating the number of vertices that will conform the face? so it could be a number ranging from 3 to infinite, so this number says how much vertices do follow after the "=" so "4 = vert1 vert2 vert3 vert4" is this true?
* amount of faces
)
}is this correct?
meshDef
{
( numVertices numFaces placeholder placeholder placeholder )
(
( posX, posY, posZ, posU, posV ,normalX, nomalY, normalZ )
* amount of vertices
)
(
"material" numVertexIndices = index0 index1 ...
* amount of faces
)
}
great thanks!
I wonder, could we left the possibility of n weight channels per vertex, for future expansion of the tech?
so in the future we could paint flora and effects via n weight channels
it could go like this:
( posX, posY, posZ, posU, posV ,normalX, nomalY, normalZ ) ( wheight0 wheight1 ... weightn )
* amount of vertices
so wheight0 would be the amount of weight that vertex has on channel 0, channel 0 being whatever we ask it to be through the code.
what do you think?
The vertex information is mapped to idDrawVert. So you only have 2 RGBA channels with color information.
But terrain rendering with vertex color interpolation sucks. I did a lot terrain rendering research for a commercial project and it is the best to use multiple splat maps and write a tool how to mix them.
Simply use textures and each channel references an albedo/normal combination. It would require a terrain interaction shader but is worth. Sikkpin did something similar.
but it could be useful on other than combining textures, maybe we can do our own DrawVert with n channels?
this way we could paint trees and other plants, and also paint effects in the vertex
for strictly terrain texture there is the megatexture tech for doom3 which is somewhat more limited than the stuff on quake wars enemy territory but somewhere in the web there is that mod.
a splat map is a map made of several positioned and rotated decals all forming a mega texture?