Dragofer
-
Posts
2634 -
Joined
-
Last visited
-
Days Won
157
Posts posted by Dragofer
-
-
the caulk texture lets light through, it will seal an area but you can see through it, eg if you have a predefined skybox, and have some parts with the skyportal texture and some caulk, caulk acts the same way as the skyportal texture and the sky will render on the caulk when in game. if you don't have a skybox defined the the caulk in game will show the void, and parts of your map that you wouldn't want players to see.
Yes, the caulk wouldn't be good to use like this in a real map. I'd use it in this testmap though because that effect lets you see if certain objects are being rendered even though their visleaf is closed. If anything it saves having to type r_showtris.
-
Thank you!
I've been wondering why we don't have denominations of builders, same models wearing green or brown or gold, along with the red.
Sub Zero, Scorpion and Reptile are all the same sprite with a different color outfit.
Imagination makes them seem individual characters.
Yes, that would be a very simple photoshop if any mapper ever wanted to work with a different order of the religion - maybe a seclusive sect, or a town so distant from Bridgeport that religious practice follows an unfamiliar doctrine. Just as Rome and Constantinople were opposing centres of religious authority.
It could go further still and be a difference on a level like Catholicism and Protestantism (Calvinism). In the colder northern regions you could find a Builder order whose followers wear grey or black, live strict and simple lives and who build plain churches with no adornments. No golden builder symbols or candlesticks. Although closer inspection of the Bishop's chambers by a thief might reveal a sizeable stash of valuables.
I'm sure there were long discussions of having several orders in the core assets, for example if there should be Mechanists. The concensus turned out to be one order, which looks to me like it's midway between Hammerites and Mechanists - their symbol is a hammer and cog. Mechanically very capable, but not really into steambots, cyborgs or automated surveillance. Yet.
-
That makes sense - I haven't seen any patch func_statics leak when they were well inside the room, touching no walls.The flat-on-the-wall thing might be the problem.
If I had my mapping tools to hand now instead of in a couple days I could send you a large selection of problematic beams & co from my WIP.
I'd set up the testmap as two rooms separated by a caulk wall with a door, the player on one side and the func_statics on the other.
-
Something that's been bugging me for a while is that some patch func_statics like roof beams get rendered although I'm in a different visleaf.
For example, r_showtris or giving the walls a caulk texture shows that even though I'm standing outside the house, a lot of the beams inside the house are being rendered. (Visportals all closed)
Did anyone else have their architectural patch func_statics leak into other visleafs - and did anyone find a way to stop it?
Things I've tried so far are to:
- make sure all verts are within the room or flat on the wall
- make sure the func_static origin is inside the visleaf
- make sure no visportals cut the func_static
These don't seem to make any difference though.
-
- Popular Post
- Popular Post
Something of a ‘What are you working on’ status update after watching countless Blender vids and memorising even more Blender shortcuts. I’m pretty sure by now that every possible combination of ctrl/alt/shift and letters has a function in that program.
Here’s a brass lamp Taquito posted in the Inspiration Thread a while ago. I quite liked the style of it so that became the first thing to make a high-poly model for, minus the steampunk modifications. The low poly is at 1300 tris at the moment.
The next learning curve is to figure out how to use GIMP to turn photographs into flat model-appropriate textures. Although it didn’t really turn out that bad when I just tacked on the reference photo.
The next high-poly was this chalice. The low-poly is at 920 tris at the moment.
Just pasting the reference onto the model worked quite well again. They made the bowl with a wavy pattern, but recreating that in a model would cost a few thousand tris. Maybe a normalmap would help, but I've been fiddling for a long time now just in attempts to get the plain bowl normalmap to look... clean without triangles?
Also, strangely enough some of the trim details only show up as lone black pixels in the normalmap.
Thinking that my DarkRadiant modelling days were over, I tried importing a horse to make a properly fitted harness for my stagecoach that could follow the horse’s animations. But the importer turns up with this error (other md5meshes had no problems with being imported). Google doesn’t recognise this error unfortunately.
I'm guessing Blender isn't reliable enough to work with md5's at the moment, so back to my patchwork harness (870 tris including inner faces, no long thin tris). The close fit in this screenshot is slightly on the optimistic side though.
Did anyone notice the saddles as being strange for horses pulling a coach? The thing I'm interested in is the headpiece, but all the horses with headpieces also have saddles.
-
11
-
Eep!
It is that strict teacher who always knew you didn't do your homework!
Glasses really make people look smart. =)
I'm a big fan of the way you... diversify the existing AIs
-
2
-
-
Now that I think of it. there is a workaround here.
Ah right, that sounds like the solution. If the normalmaps overlap they could be merged, which avoids having to use the addnormals line.
-
1
-
-
I'm pretty interested in the implications of this thread - if I wanted to make a model that:
- uses a normalmap from a high-poly version
- uses a stock texture, which also has a normalmap
Would it be right to say the only way to solve the normalmap conflict is to:
- duplicate the stock texture shader and let the new one use my model's normalmap
- and therefore adapt the high-poly mesh so that it also models details in the texture
Also, as far as I know every face needs to have its own place on the UV-map in order for hi-poly normalmap baking to function, which can be a problem with stock textures that weren't designed to fit the model's UV-map.
So it looks like stock textures are fairly unsuitable for models that have a normalmap from a hi-poly version.
-
1
-
-
- Popular Post
Loved the level, any sequels to be done?
Thanks - yes there's a sequel underways. Like the first it has adventure and survival themes, and then more substantial gameplay. At the moment I'm getting more involved with Blender to make more sophisticated lamps, clocks, silverware and other objects that would fit into the scenery snugly. Fireplaces too - I can't imagine a mission of this sort without a warming fireplace as a centrepiece of almost every room, but the stock models aren't so great to work with and could really use an overhaul. I'd make a stately brass oil lamp in exchange for a comfortable fireplace.
Also, I appreciate your ghosting vid on Youtube, well done for such a thorough completion.
-
5
-
They can add it wherever they want; my point is that it should be up to mappers to decide if they want any interior lights and what kind, rather than having them built into the model.
Yes, that's what I was thinking of. My plan would be to either update the prefab with suitable existing lantern models or make a model out of a modified exterior lantern to keep the same style.
-
Thanks for your comments Sotha. It seems you've had just the experience that I was thinking of when I made this mission, even down to the cabinet under the stairs, which I'm very glad to hear. I think that's one of the best things a FM author can hope for.
-
Most carriages have external lights, but I haven't seen interior lights myself. Maybe travelling in the dark was considered too dangerous when holes and rocks on the road, let alone the road itself, can't be seen, so the constructors probably didn't see a need for lights on the inside. The exterior lanterns were probably only for decoration because they would be too weak to illuminate the road in front of the horses.
Still, interior lights would make sense to allow the occupants to generally see what they're doing. Some might want to read their notes when the coach isn't rocking them about.
There's also a gameplay side. It might be more interesting if the player has to consciously stay crouched to avoid being spotted through the windows, rather than being in an easy safe haven.
As for what they'd look like, they should be closed and firmly fixed to avoid the risk of fire. Small lanterns like Bikerdude's would fit that description.
-
Regarding optimising, I used standard textures for parts which were already simple enough to be a shadowmesh, and for parts where it would've been difficult to make a shadowmesh that uses significantly fewer tris.
Examples are the undercarriage beams and the curved body panels of the stagecoach with an interior. The closed stagecoach on the other hand allowed for a very simple shadowmesh, so most of the shadow tris there are from the wheels.
I've mostly used patches to make the coach so there was less potential for hidden faces than with brushes. If a patch beam is on top of something else I used SteveL's patch splitter to get rid of the hidden side. When converting the stagecoach to a closed version I deleted any faces that could only be seen from inside - much easier with the patch splitter. I did spend some time caulking unseen faces in the sidelanterns because they're made mostly of brushes - very fiddly and could've been avoided by making those out of patches too.
That's what I've done, though I'm always interested to hear of other ways to approach optimising.
-
Great, I appreciate that you looked so closely at it. I also do like that testmap, much more going on there than in mine.
It should work to allow AIs to enter and sit inside the stagecoach. Imagine seeing the lord arriving and stepping out of his stagecoach to take up affairs at his estate. Or spotting a noble from afar through the window of his stagecoach, travelling through the streets of the city. Kind of like a crow.[*]reins for the horses
If attaching AI horses to the stagecoach, I'm not sure what to do if the player shoos away the horses - maybe the reins should fall off? Things would be much easier if all players always played by the rules.
[*]interior lights.
Yes that would be good to have by default, especially considering your testmap was fine with lights all over the coach - I'm guessing you made them noshadows, small radius and bright_square (the light texture with less dropoff)
[*]the seat is 8 units to high for Ai (coachman) to sit down.
I like how you've put someone up there
What will he do if he ever wants to get down?[*]imho, the glass on the outside lights should be clear.
Do you mean clearer, less opaque? At the moment they share a transparent glass texture with the chassis windows.
The elevator system could be a place to look for a way to transport AIs. The stagecoach would stop - if it stops - inside fitting monsterclip brushes. Then the map would have to prevent that the player alerts/shoots an arrow/gets in the way, physically or with objectives.
-
Next up
The stagecoach in model format. Using the stagecoach is more straightforward and no longer increases the map’s number of patches by close to 1000, which would be noticeable in loading and dmap times. It also allows for skins.
Download:
[bsolete]
What’s in this package:
•Models: complete stagecoach with or without interior, also front and rear wheel models, left & right door models, and a version each of those stagecoaches without wheels attached (i.e. if the stagecoach lost a wheel)
•Skins: seats in 4 colours or leather for the stagecoach with interior. Windows as default unlit or colorme for the stagecoach without interior in case the default windows should be darker.
•Prefabs: stagecoach with or without interior, setup with doors or windows as I’d have intended them. Also 2 unlit candles inside the lanterns.
•Materials: noshadows versions of dark_rough, beam_rusty_victorian and the 4 armchair skins. I’ve put the first 2 where the other model textures are to avoid adding clutter to the wood and metal textures menus.
You'll find them at:
Create model -> darkmod -> misc -> carriages
More technical details:
- The stagecoaches use a mixture of noshadows materials and shadow meshes. The interior stagecoach has just above 4000 shadowcasting polys, the one without has 2000 shadowcasting polys.
- The prefabs can be rotated.
- Here’s the source file (I’ve also updated my previous sphere lamps post for this): Dropbox
-
4
-
-
To get a diagonal brush what I do is to make a large normal brush, then use the clipper tool to make a diagonal cut starting from one of the corners.
You'll need to carefully count out the squares up and to the side, because making random slopes like 3:17 can cause a mess with the engine. I've restricted myself to slopes of 1:1, 1:2, 1:4 and 1:8 squares. Slopes of 1:3, 2:3 and 1:6 only if there's no other way and if the line can end on a whole number of squares both up and to the side.
The .ase exporter in DR is meant to take a group of brushes and patches you made and turn them into a model. That makes it easier and more efficient to use again if you need to use it many times.
-
1
-
-
- Popular Post
- Popular Post
Here are the finished sphere lamps:
[Obsolete]
What's in this package: smoothed models in .lwo format with gold, silver and brass skins, and a steampunk skin that uses a different UV map so it has its own model. They are all available as lamp entities.
You will find them in:
Create model -> models -> darkmod -> lights -> non-extinguishable -> sphere_wall
Create entity -> darkmod -> lights -> model lights, static -> switchable -> electric -> indoor -> sphere_wall
The light bulbs can be recoloured with _color - the standard appearance is white. I think the tdm_glare_lamp_01 particle goes very well with a white or yellow bulb.
Christmas lamps
Steampunk skin
More technical details:
Install: extract the zip to the main darkmod folder, then restart DarkRadiant/TDM.
The lamp origin is 16 units from the backplate to make them easier to fit to walls.
There are 4 combinations between single/double bulbs and straight/curved pipes and a 5th single-curved lamp with a steampunk skin, although there are only subtle differences between the pipe types. So if you don't need so many combos just remove some of the def files. The skin file's model allocations and the model folder would need to be updated afterwards. Personally I think the single/straight and double/curved combinations look best.
The default lit setup of the lamp entity is colorme and _colour is set to appear white. The plain lit skin always has a yellow bulb.
I used noshadows materials on parts of the lamps so that there are roughly 500 or 1000 shadowcasting polys per lamp depending on bulb number. When they are lit the skin (and the def) turns the entire lamp to noshadows.
Here's the source file in Blender: Dropbox
-
7
-
Adding in glare particles for the lamps didn't work so well. They seem to stay active no matter if the lamp is on or off. I've tried using "start_off" or "extinguished", putting a "toggle light" or "trigger" response on the lamp entity, triggering the lamps with a premade lever, there's always the glare. The existing arc light also has particles that won't switch off, so it makes me wonder whether it's a bug?
What can be done instead is to leave it up to the mapper to put in their own particles, and it looks decent enough without particles. Although it saves some effort, and might help new mappers if the lamps already came premade with particles.
Here's the view at my testing range:
To lighten up the mood amid all this testing: lamps in all colours using _color spawnarg. Maybe for a christmas mission, or some sinister place that wants purple/dark blue lamps.
(The colour is much more evident when there's no particle, maybe that's going to be the main argument to make them appear without particles by default. This screenshot also shows the problem my lamps and some of the stock electric lamps have with barely lighting up their own walls.)
-
1
-
-
I've got my finally smooth spherical lamps set up as lamp entities and they're working normally except that there seems to be a problem with the light origin.
My lamps don't illuminate the wall they're mounted on unless I move the model's origin or the whole lamp forward 16ish units.
It seems the light diamond is too close to the wall: in DarkRadiant the light diamond shows up at the model origin, which is always the backplate of the wall mounting. That's even though I've changed the spawnarg for light_centre_offset to put the light centre inside the bulb. (Note that I'm inheriting from the quiet electric light template)
Also, I've seen that the existing electric fancy wall lights have this problem too and fit the above description.
Is there an extra line in the def that can move the light diamond away from the wall? Or would it require changing the model origins?
-
1
-
-
Contact is back up, no worries and my apologies for the wait.
-
Here is a revised version:
Great, this worked exactly as it should. Thanks for posting this here Xcen.
Now to setup the new custom light entities. The wiki as far as I can find doesn't seem to have something about setting up new lamp entities, but the existing lamp definitions describe the spawnargs well already.
-
Just wondering if the smoothing issue with the gas lights ever got resolved?
If so, was a light entity prefab created for them?
The setup of reverting to a slightly older version of Blender (2.70) and using exporters made with TDM in mind was promising because it produced properly smoothed test objects like a metal sphere and torus. But when I made a new copy of one of those lamps from scratch in Blender 2.70 it had the same smoothing problem again: metal is flat, glass is smoothed. There must be a problem with how I've set up the lamp at some point while modelling it.
On a sidenote, I've seen now that even the old setup in Blender 2.74 is capable of making properly smoothed test objects, so it's unclear whether reverting to 2.70 was needed.
I'd very much appreciate if someone else who uses Blender tried to export what I have. This package has both the original and the remade .blend files, the .lwo exporter that I use (also .ase) and an already exported .lwo model:
https://www.dropbox.com/s/ugb26n73t1kjuxl/spherelamp.rar?dl=0
-
- Popular Post
- Popular Post
Work is back on track after a bit of a pause and Of Brambles and Thorns has breached the 25000 brushes, patches & entities mark. Storywise I'm still looking for that knot that ties everything together in the end but things are more and more coming together. As for when it's finished, it looks like this one's going to be a long haul with all the bells and whistles so plenty to go.
-
5
-
Particles: better with or without?
(Ignore anything you can make out of the ceiling; it's a placeholder.)
Looks very mysterious, with the particles.
Recommendation: Wings3D Tutorial for beginners
in TDM Editors Guild
Posted
I've looked through the video tutorials available - what I was looking for was a user-friendly beginner's walkthrough for making a simple object as that would show many of the tools in action. The best bet imo is to follow the instructions in 'modelling a simple table'. Before starting it would be good to create a .txt file where you can record every shortcut mentioned.
From there I'd suggest to make a simple model from start to finish, like a cartwheel. That way you'd learn everything needed: how to manipulate a mesh, how to texture, how to export etc. Whenever you need to know how something is done in Wings3d, Youtube or Google will be handy for a quick tutorial.