OrbWeaver
-
Posts
8725 -
Joined
-
Last visited
-
Days Won
81
Posts posted by OrbWeaver
-
-
DarkRadiant 0.5.1 is available from SourceForge:
http://sourceforge.net/project/showfiles.p...lease_id=434137
Fixes:
- Changing an entity keyvalue now sets the map status to changed so it can be saved
- Dragging a model now updates in realtime, rather than waiting for the drag to finish
- Textures should now display correctly on ASE models
- Application should not crash on Window 2000 due to the presence of global.xlink (which has been removed anyway).
Enhancements:
The huge right-click entity menu is GONE. Instead there is a context menu with options to add a light, model, entity and (eventually) a prefab at the current location. The selection of an entity uses a separate dialog with an alphabetical list of all entity classes (with typeahead search).
-
7 out of 10. Most of them were guesses, I really had no idea.
-
* Dragging static meshes does not update the position until the drag has finished. The "Translate" button on the toolbar activates the translation manipulator, which makes this a bit easier until it is properly fixed. Under investigation.
Fixed upstream in GtkRadiant, merged into trunk.
-
One interesting thing I noticed is that the demand definitely does not seem to be linear with respect to what's thrown up on the screen. When I turn so that just a few spheres are on screen, the hit is huge, but as I turn more so that more are visible, the performance hit increases at a decreasing rate. Probably some kind of magical J.C. optimization doing that. Then again, because of that, my results might be somewhat worthless because the magnitude of hit in comparison to how close they're both approaching zero.
I wonder if this is related to what Gildoran was saying about Doom 3 expecting hardware to be fillrate-limited rather than transform-limited. Perhaps in a Geforce 4 the two are more or less the same, so that sometimes one dominates the other and vice versa.
-
But does this mean we can't see render mode while editing? That is a really BIG drawback I think! Perhaps it isn't really
There is a render mode, available by pressing F3. Currently it is very limited and only displays a rough approximating to Doom 3, with simple lights (no custom textures) and no shadows. Hopefully the framework is enough for further improvements; unfortunately I am not yet much of an OpenGL/graphics programmer so I don't know how easy it will be to add these features.
-
Bug:
ambientlightnfo and ambientlight_nofall do not render in the darkradiant preview. Everything is completely black.
Funny, I was just thinking about posting this bug yesterday. In fact the preview window completely ignores light textures as far as I can tell, and assumes a simple spherical falloff in all cases.
-
Welll... that involves creating material files for all my textures with the ambient light tutorial I have.
No it doesn't. You can use multiple light sources, including some with a suitable ambient lightshader applied.
I thought that was the Doom 3 engine. I thought that went without saying.Only if you make it so. You can use as many light sources as you wish, although don't go too far above 2 or 3 if you can avoid it for performance reasons. Pitch black shadows do not exist in real life because there is always another source of light.
-
More detail, less flat texturing and blocky architecture.
More subtletly, fewer extremes of light and dark (most of those shots only have one light source, everything in shadow is black).
Less garish, cartoony colours.
More of a coherent visual impression, less ad-hoc placement of random objects and brushes with no overriding style.
HTH.
-
I wouldn't describe it as awesome, but it's certainly improving.
-
Yeah, the only way to do true volumetric fog is by using a particle effect. Perhaps you could modify your snow/rain emitting texture to emit very large, slow-moving smokepuff particles (which look good as fog if they are sufficiently faint). You might not even have a performace issue if you used large enough sprites, as you would not need that many.
-
ASE model/shader not found issue now fixed in trunk. Trees are textured correctly in tavern.map.
-
Instead of binding to player you could also just use a huge foglight that encompasses the whole level (which can itself be the receipient of scripted events based on player position). Since a foglight is not really a light this will not impact performance.
-
What does LSCM mean?
Least Squares Conformal Map (also Laser Scanning Confocal Microscopy). It has something to do with the algorithm and the way it tries to preserve local angles.
Cool spider BTW, I have made several attempts to model a spider in Blender but never quite managed to get the proportions right.
-
LSCM, yes.
Maybe that name can also be found in LW somewhere?I get the impression that LSCM support is actually rare, and Blender is one of the few applications that has it (and quite possibly the only Free one).
-
Do you mean LSCM?
I can look at an LWO in Blender and tell if it definitely is UV-mapped, although I don't have sufficient confidence in the import script to declare that it isn't (since it may have one, but the script failed to import it).
-
* Quite a lot of models and geometry show up as "shader not found" in the preview even though they work in game. Under investigation.
One cause of this problem has been identified (it may not be the only one). DarkRadiant is incorrectly attempting to use the *MATERIAL_NAME rather than *BITMAP to identify the Doom 3 shader to use for an ASE model. As a temporary workaround you can make an ASE model render correctly by editing the *MATERIAL_NAME to specify the Doom 3 shader.
-
But it does obey the light texture. I've already tried this.
Can we see some shots, or a tutorial? Neither I nor SneaksieDave were able to get this to work.
-
At the least, you're surely going to do adequate research into the way people spoke in medieval England and only use words which they would have used?
I'd like to see the adequate research that demonstrates that the modern-sounding swearwords and phrases in question ("What the fuck?" etc) were actually widely-used by the medieval population in the same way they are now, rather than just appearing in a modified form in the occasional piece of Shakespeare.
-
*make the map first (of course) then get the exact outline of where you want the fog to go and create a large image (2048x2048?) that has the transitions you want. Use this as your lighttexture etc.
If the fog doesn't obey the light texture (which it seems not to), this won't work.
The only other solution I have is to use the bind light at map start thingy. Though that means the fog is always with you.Yes, but you can script the light to change intensity, colour or fog density (shaderParm 3 I think) based on the player's position.
-
-
I'm sure I do somwhere, I'll try and dig it out. As I recall I actually had to remodel the object since the low-poly mesh structure was crap (it had been decimated from the high-poly model).
As with most of my models the texture was not spectacular but the addition of a UV map allows a more skilled texture artist to take over if required.
-
I quite liked Blenders approach and after watching a video tutorial on how to use it I found it very easy and intuitive.
Have you tried the Live LSCM feature in later releases of Blender yet? You can produce your original unwrapping, pin some vertices, move them around and watch the entire map deform in realtime as you drag.
Also there are some new additions in 2.42, including an "Angle-based" unwrap which is supposedly better than LSCM (something to do with warping, I haven't investigated much), and much easier seam-creation tools (just choose two points on either side of a model and Blender will create a seam automatically along the shortest path between them).
-
It looks like the reason it behaves differently is because it's using a falloff image. In lights and fogs, a stage defines the x/y axies, and the falloff image defines the z-axis... (of course, a light can have its axies rotated) Unfortunately, I'm not exactly sure how it combines the falloff and cross-section to yield the color at a specfici point... perhaps it multiplies the colors together?
I presume it does a multiplication for ordinary lights, but foglights are different. They are not actually lights as such, I believe they just blend their colour with the remote surface based on the distance between the player and that surface. I am not quite sure how the falloff images fit into this, certainly in my tests I was unable to make a foglight use biground1.tga to create circular fog, for instance.
-
I've had an idea for a map with some misty ruins, and a deep gaping hole in the ground leading down into some fogless chambers. I planned on doing the transition by adjusting the blendlight fog in intensity as the player based on the player's Z-position in the hole. (I've done similar things to adjust the brightness of fog in water based on a player's Z-position, so that water appears darker the deeper you go)
Vertical falloff works OK if you use the texture "pitfog_to_black". This suggests that it should be possible to have a fog which falls off in any direction, not just vertical, but even looking at the MTR I couldn't really understand what pitfog_to_black is doing.
The other alternative is to bind a very large foglight to the player's position, and script it so that the intensity is modified when the player enters/exits certain areas. This is more or less how Thief did it (except that it was done by the engine, not by the mapper explicitly placing a light).
Task: Set Up Moveables
in Art Assets
Posted
Yes. Yes.
If you zoom in small you should be able to fit the brush to the size of the model fairly well. You can also shave off parts of the brush with the clipper tool before exporting, as long as it remains a single convex brush.