A few questions about constructor and art assets in general-
by Brian Barnson · in Constructor · 07/06/2009 (10:56 am) · 3 replies
I am a mapper/asset artist working essentially full time while I seek out a paying job.. That means that currently I have a LOT more time, in general, than the coder who is actually doing the work on the game I am working on (Frayed Knights full version)so I am hoping to have to find as many solutions as I can without resorting to asking him to code stuff.. he has a ton of work on his plate already so I am trying to make sure as much of the asset work as possible is squarely on my shoulders. In that vein, I would like to ask a few questions about some of the more technical side of constructor. (and .dts file creation, as well...)
Please bear in mind that these are questions about building classic dungeons, and they need to be inserted into existing terrain. They are intended for TGE and not TGEA or T3D, since we cannot afford to purchase these yet. taking advantage of TGE's heightmaps as part of dungeon design is not really an option, as these need to be inserted through an empty area to create 'underground', classic, dungeons.
1) I have been poking around, and realized that without hard-coded .dif water, I will need to come up with a unique water solution, so I thought of a couple of ideas:
A. is it possible to link a brush to a generic, homemade 'water'entity, and allow a coder to easily access that entity to turn it into 'water'? will such an entity cast shadows, and is there a way to make sure it does not?
B. 'swimming' is not implemented or intended to be implemented. to ease the coder's workload, I might simply make a large plane in blender with a 'water' alpha-blended animation on it. Will this work?
I) assuming that solution B is possible, is it possible to do so without applying a collision box, and if I don't apply a collision box, will that allow the water to ignore 'shadows'?
II) If I do apply a collision box, (walking on water that is only a few inches deep probably won't break immersion) will that collision box 'shadow' be only the collision box itself, or will it allow the shadow engine to cast 'semitranslucent' shadows based on the texture's alpha filter?
III) Will a 'NULL' textured collision box as a .dif object work? how would I set one up, simply set it as a collision shape and then apply a null texture? if I set a null texture on the 'top' of the water, and a texture on the bottom, will the players see the inverted texture through the shape, or are brush surfaces single-sided?
2) How many brushes are the maximum for 'new' constructor version 1.06? I know the old version was 2k, and that the number was increased in a newer version... a hopeful development, since any reasonably sized dungeon will easily exceed 2000 brushes even with careful brush management. This game is intended to run as best possible on older machines, so I am portalling QUITE aggressively.
A. would it be more efficient to make most of the walls/areas as .dts meshes?
I) Do DTS objects dissappear due to portalling, the same way brushes do?
II) Should I have jay set up a DTS portalling solution, to use in conjunction with standard portalling? I have seen several outstanding and simple coding solutions presented elsewhere on these boards, and if these are cut-and paste, I would be happy to recommend them to Jay.
B. do collision box shadows allow light to interact with the geometry of a dts object? or only with the shape of the collision box itself? for instance, if I make a dts 'wall' with complicated geometry, such as stanchions, a widow, and a rope hanging from the wall, do I need to create a form-fitting collision box for the shadows to interact correctly with the various surface projections, or will a simple box that covers them all and prevents players from walking through the wall suffice?
I) would this collision box be effective if created as a null-textured .dif brush instead of as part of the dts file itself?
II) How do 'vehicle collisions' differ from a standard collision flag?
3) Are null textured brushes rendered as faces? I understand that they cast shadows, but do they still cast shadows if they are flagged as 'collision' instead of 'structure' or 'detail'?
4) do detail and collision brushes perform hidden face removal against objects of their own type?
A. How do collision brushes differ from structure and detail brushes?
B. Do collision brushes perform HFR against detail/structure brushes?
C. Do Detail brushes perform HFS against collision brushes?
D. do dts objects or dts collision boxes perform HFS against anything? do collision boxes inside dts objects pertform HFS against other collision brushes or boxes either outside or inside the DTS?
5) If/when we finally get T3d, will constructor and dts assets still be applicable to a new game?
and finally:
6) is there a way to apply detailmaps or bump maps to any textures whatsoever, either in blender for creating dts maps (although I haven't figured out how it would work with the exporter) or in constructor?
Sorry about the MONSTER list of questions, but a lot of these things have been plaguing me tremendously as I attempt to create art/level assets for the game. answers to any of these questions would be hugely appreciated, and I didn't want to make this list until after the 4th weekend :)
Please bear in mind that these are questions about building classic dungeons, and they need to be inserted into existing terrain. They are intended for TGE and not TGEA or T3D, since we cannot afford to purchase these yet. taking advantage of TGE's heightmaps as part of dungeon design is not really an option, as these need to be inserted through an empty area to create 'underground', classic, dungeons.
1) I have been poking around, and realized that without hard-coded .dif water, I will need to come up with a unique water solution, so I thought of a couple of ideas:
A. is it possible to link a brush to a generic, homemade 'water'entity, and allow a coder to easily access that entity to turn it into 'water'? will such an entity cast shadows, and is there a way to make sure it does not?
B. 'swimming' is not implemented or intended to be implemented. to ease the coder's workload, I might simply make a large plane in blender with a 'water' alpha-blended animation on it. Will this work?
I) assuming that solution B is possible, is it possible to do so without applying a collision box, and if I don't apply a collision box, will that allow the water to ignore 'shadows'?
II) If I do apply a collision box, (walking on water that is only a few inches deep probably won't break immersion) will that collision box 'shadow' be only the collision box itself, or will it allow the shadow engine to cast 'semitranslucent' shadows based on the texture's alpha filter?
III) Will a 'NULL' textured collision box as a .dif object work? how would I set one up, simply set it as a collision shape and then apply a null texture? if I set a null texture on the 'top' of the water, and a texture on the bottom, will the players see the inverted texture through the shape, or are brush surfaces single-sided?
2) How many brushes are the maximum for 'new' constructor version 1.06? I know the old version was 2k, and that the number was increased in a newer version... a hopeful development, since any reasonably sized dungeon will easily exceed 2000 brushes even with careful brush management. This game is intended to run as best possible on older machines, so I am portalling QUITE aggressively.
A. would it be more efficient to make most of the walls/areas as .dts meshes?
I) Do DTS objects dissappear due to portalling, the same way brushes do?
II) Should I have jay set up a DTS portalling solution, to use in conjunction with standard portalling? I have seen several outstanding and simple coding solutions presented elsewhere on these boards, and if these are cut-and paste, I would be happy to recommend them to Jay.
B. do collision box shadows allow light to interact with the geometry of a dts object? or only with the shape of the collision box itself? for instance, if I make a dts 'wall' with complicated geometry, such as stanchions, a widow, and a rope hanging from the wall, do I need to create a form-fitting collision box for the shadows to interact correctly with the various surface projections, or will a simple box that covers them all and prevents players from walking through the wall suffice?
I) would this collision box be effective if created as a null-textured .dif brush instead of as part of the dts file itself?
II) How do 'vehicle collisions' differ from a standard collision flag?
3) Are null textured brushes rendered as faces? I understand that they cast shadows, but do they still cast shadows if they are flagged as 'collision' instead of 'structure' or 'detail'?
4) do detail and collision brushes perform hidden face removal against objects of their own type?
A. How do collision brushes differ from structure and detail brushes?
B. Do collision brushes perform HFR against detail/structure brushes?
C. Do Detail brushes perform HFS against collision brushes?
D. do dts objects or dts collision boxes perform HFS against anything? do collision boxes inside dts objects pertform HFS against other collision brushes or boxes either outside or inside the DTS?
5) If/when we finally get T3d, will constructor and dts assets still be applicable to a new game?
and finally:
6) is there a way to apply detailmaps or bump maps to any textures whatsoever, either in blender for creating dts maps (although I haven't figured out how it would work with the exporter) or in constructor?
Sorry about the MONSTER list of questions, but a lot of these things have been plaguing me tremendously as I attempt to create art/level assets for the game. answers to any of these questions would be hugely appreciated, and I didn't want to make this list until after the 4th weekend :)
#2
you can always place a water block inside a dif (or so that it intersects through a dif.
07/07/2009 (10:33 pm)
Heres answers to some of your questions...Quote:A. is it possible to link a brush to a generic, homemade 'water'entity, and allow a coder to easily access that entity to turn it into 'water'? will such an entity cast shadows, and is there a way to make sure it does not?Why not use waterblocks that come with TGE?
Quote:I've not tried it but a DIF with all null textures should still have collision.
B. 'swimming' is not implemented or intended to be implemented. to ease the coder's workload, I might simply make a large plane in blender with a 'water' alpha-blended animation on it. Will this work?
I) assuming that solution B is possible, is it possible to do so without applying a collision box, and if I don't apply a collision box, will that allow the water to ignore 'shadows'?
II) If I do apply a collision box, (walking on water that is only a few inches deep probably won't break immersion) will that collision box 'shadow' be only the collision box itself, or will it allow the shadow engine to cast 'semitranslucent' shadows based on the texture's alpha filter?
III) Will a 'NULL' textured collision box as a .dif object work? how would I set one up, simply set it as a collision shape and then apply a null texture? if I set a null texture on the 'top' of the water, and a texture on the bottom, will the players see the inverted texture through the shape, or are brush surfaces single-sided?
you can always place a water block inside a dif (or so that it intersects through a dif.
Quote:Do DTS objects dissappear due to portalling, the same way brushes do?Yes, you won't need to do anything programming wise. Just check that your portals work. The easiest way to make them all 'light does not pass through' and check they are all dark when you enter them.
Quote:4) do detail and collision brushes perform hidden face removal against objects of their own type?My understanding is the HFR (or HSR - Hidden Surface Removal) occurs when the face is facing away from the camera, or when the brush is in another zone that cannot be seen into (portalling)
Quote:6) is there a way to apply detailmaps or bump maps to any textures whatsoever, either in blender for creating dts maps (although I haven't figured out how it would work with the exporter) or in constructor?In TGE, No, not without greatly modifying the engine.
#3
After several completed dungeons for the game, I was beginning to realize that the brush system was beginning to look a little too formulaic, as well as constructor itself having some rather glaring bugs which become especially apparent when modeling large or natural- looking interiors, such as caves. This is possibly not the fault of constructor, but of the csg system itself. There's also the time factor to consider... in the time I could create one natural-looking rock projection in constructor, I would create an entire low-poly rock face in something like blender, complete with skinning, 100 or so faces, and a reasonable 4-9 block collision mesh. The game is not about movement, so there's no jumping or swimming or flying enabled.
So I kind of decided to go with a combination of mesh walls and ceilings, a reasonably-sized collision along the bottoms of the walls to prevent players from sticking body parts through them, and csg 'walkable areas' (where good collision is actually essential) such as ledges, floors, slopes, and artificial simple construction (for example, an underground rampart might be blocked out in csg with mesh 'facades' for greater detail.) and so far it is looking and working quite well. I am also using CSG to create 'mortar' and box in mesh areas, so that I can heavily portal and take advantage of one of the best features of CSG, it's ability to vis block.
I WAS hoping to be able to create the meshes themselves in blender and then use constructor to create the actual clipping brushes, but then I discovered something... when clipping brushes with invisible texture are connected to a structure brush, such as a floor, exactly, the floor's texture where it is in contact with the invisible brush dissappears!
The only way I could see that happening, reasonably, is if the HSR is removing the invisibly-textured collision brush faces themselves and cutting into the structure brushes to remove the faces 'hidden' by the collision brush, which essentially means that collision brushes are identical to structure brushes and are therefore totally unsuitable for my needs... and I was wondering if this were true or if I simply screwed something up without knowing what it is.
As far as the water blocks, that is actually pretty simple... I have to pack up maps and email them to the lead dev, ready to be dropped into an already-existing game. That means exclusively dif objects (or difs with DTS objects) since I cannot include TGE editor heightmaps or other add-ins. Unless there is some way to include such an object in the TGE editor, save it, and have it apply to a different worldmap when dropped in with a dif? So far I haven't seen a 'cut' function in TGE editor :). Besides, I am not sure if, legally, I am permitted to actually USE the TGE editor since the license is the lead's, not mine. All I have is a carefully crafted gamedemo testing platform.
As far as the detail maps, I did discover that DTS objects CAN include detail textures, but as you mentioned, I think the actual detail map functionality is only enabled, by default, in TGEA. The project is already rather advanced in basic TGE, and it's a little too late to change now (Although one can always hope that sales will be enough to at least afford a couple of t3d licenses for the next release, although we will probably continue to use dif vis blocking because polysoup physics will totally lag the target audience)If we want to release any time this year. I mean, map relighting alone takes a good block of time.
So I keep trying to come up with low-coding or self-inflicted solutions to issues with HUGE undergound dungeons and their innate brush and surface limitations, and leave the lead alone to wrestle with the problems only he can fix, like a good merchant system and trap and door coding. ook ook. me lowbrow artist, not unnerstan 'hello world' stuffs.
07/08/2009 (9:35 am)
Awesome, thank you for the reply.After several completed dungeons for the game, I was beginning to realize that the brush system was beginning to look a little too formulaic, as well as constructor itself having some rather glaring bugs which become especially apparent when modeling large or natural- looking interiors, such as caves. This is possibly not the fault of constructor, but of the csg system itself. There's also the time factor to consider... in the time I could create one natural-looking rock projection in constructor, I would create an entire low-poly rock face in something like blender, complete with skinning, 100 or so faces, and a reasonable 4-9 block collision mesh. The game is not about movement, so there's no jumping or swimming or flying enabled.
So I kind of decided to go with a combination of mesh walls and ceilings, a reasonably-sized collision along the bottoms of the walls to prevent players from sticking body parts through them, and csg 'walkable areas' (where good collision is actually essential) such as ledges, floors, slopes, and artificial simple construction (for example, an underground rampart might be blocked out in csg with mesh 'facades' for greater detail.) and so far it is looking and working quite well. I am also using CSG to create 'mortar' and box in mesh areas, so that I can heavily portal and take advantage of one of the best features of CSG, it's ability to vis block.
I WAS hoping to be able to create the meshes themselves in blender and then use constructor to create the actual clipping brushes, but then I discovered something... when clipping brushes with invisible texture are connected to a structure brush, such as a floor, exactly, the floor's texture where it is in contact with the invisible brush dissappears!
The only way I could see that happening, reasonably, is if the HSR is removing the invisibly-textured collision brush faces themselves and cutting into the structure brushes to remove the faces 'hidden' by the collision brush, which essentially means that collision brushes are identical to structure brushes and are therefore totally unsuitable for my needs... and I was wondering if this were true or if I simply screwed something up without knowing what it is.
As far as the water blocks, that is actually pretty simple... I have to pack up maps and email them to the lead dev, ready to be dropped into an already-existing game. That means exclusively dif objects (or difs with DTS objects) since I cannot include TGE editor heightmaps or other add-ins. Unless there is some way to include such an object in the TGE editor, save it, and have it apply to a different worldmap when dropped in with a dif? So far I haven't seen a 'cut' function in TGE editor :). Besides, I am not sure if, legally, I am permitted to actually USE the TGE editor since the license is the lead's, not mine. All I have is a carefully crafted gamedemo testing platform.
As far as the detail maps, I did discover that DTS objects CAN include detail textures, but as you mentioned, I think the actual detail map functionality is only enabled, by default, in TGEA. The project is already rather advanced in basic TGE, and it's a little too late to change now (Although one can always hope that sales will be enough to at least afford a couple of t3d licenses for the next release, although we will probably continue to use dif vis blocking because polysoup physics will totally lag the target audience)If we want to release any time this year. I mean, map relighting alone takes a good block of time.
So I keep trying to come up with low-coding or self-inflicted solutions to issues with HUGE undergound dungeons and their innate brush and surface limitations, and leave the lead alone to wrestle with the problems only he can fix, like a good merchant system and trap and door coding. ook ook. me lowbrow artist, not unnerstan 'hello world' stuffs.
Brian Barnson