OrbWeaver
-
Posts
8726 -
Joined
-
Last visited
-
Days Won
81
Posts posted by OrbWeaver
-
-
I keep thinking I should learn German, it seems like a really logical language (like Latin) without all of the pronounciation issues of French.
Russian is similar apparently, and very easy for scientists and engineers to learn due to its regularity.
-
That's schadenfreude. I guess they're pretty similar in meaning though.
-
Schadenfroh is "mischievous" or "maliciously cheerful".
-
Unfortunately such a system fails the most basic cost/benefit analysis.
Cost: considerable algorithmic and coding issues relating to detecting how "well" the player is performing.
Benefit: most players probably wouldn't even notice, others would find it frustrating
-
FIXED
Edited by NH:
Moved Spider discussion to off topic.
-
All I meant was that because your automated entity placement doesn’t use the original brush there is no brush model for the func_door command to refer to. It needs a model. It would use the brush model but since there isn’t one ...how can it
Maybe I am totally wrong but I think if you tried to do any of the func_x that would normally use the brush as the model you will find that none of them work but do when there is a model
You are more or less right, the selected brush should be added as a child of the func_door, but this is not happening. It is not just a problem with the naming, but with the child/parent relationship that is maintained by DarkRadiant (all brushes have to be children of an entity, usually this is worldspawn but it can be func_static, func_door and others).
-
Yep, it is a bug and it looks like it was introduced when I completely rewrote the entityDef parsing code to support our "atdm:" prefix. In vanilla GtkRadiant you can create a func_door with a brush as its child, whereas in DarkRadiant the brush remains a child of the worldspawn and the func_door entity has no children (making it useless and unselectable).
-
1 lower memory usage compared to doomedit
It's probably not fair to compare the two, since with DoomEdit you have the whole game loaded as well. Nevertheless DarkRadiant having acceptable memory usage is a good start.
2 camera movementI agree, this is much easier to use.
3 the direction right click is going is a good direction clean but usefulGlad you like it.
4 I like texture menu just loads all the textures I select.Yep, this should improve with the Media Browser, which will allow you to load any individual texture or group of textures into the texture preview window.
3 Entity inspectors is missing GUI, SOUND, SKIN, MODEL, preview button and preview window.These won't take the form of buttons, but of Property Editors in the Entity Inspector. I.e. when you select the "model" or "skin" property, a widget will be displayed allowing you to browse these DoomEdit-style.
4 I miss pressing J to bring up the light inspectorInitially I was planning to do a separate light inspector, but decided to merge this functionality into the Entity Inspector. I might consider a dedicated dialog for lights if enough people request it, but it's not a priority at the moment.
Though the entity inspector does not have usage information available if it does get added it should expand on doomedits limited usage information by giving both side of the usage example:The usage information is parsed directly from the entity definitions, there won't be any way to expand on the information that the developers put into the DEF files.
-
::common brown barn spider:::orb
Heh, there's more than one species, Argiope probably being the most interesting.
actualy i was creating a trigger_relay just as i was typing so i could get myself strait. to see if i was typing something i should have looked harder to figure out myselfwhen i finished adding the property delay 1 it locked up the entire program. i had troubel closing it for a few minutes. getting xp to dump it ...
I suspect what happened is that the All Properties dialog got hidden behind one of the other windows, giving the illusion that the program had crashed when in fact the application was just waiting for the dialog to close. I haven't yet found a solution to this problem which works reliably across both Linux and Windows.
also when i refered to the CREAT button i meant the button on the enity inpector in doom3 edit. it allows a selected brush to be converted to whatever entity class that apears in the dropdown menu when you press itclear yes or no
I see what you mean. I don't actually remember such as function in DoomEdit, suggesting that I never found cause to use it. As New Horizon said, this function will be handled by the right-click Create Entity dialog rather than as a separate button on the Entity Inspector.
-
how do i add a property in the entity inspector
The entity inspector works differently to the DoomEdit version, and more like the Thief/Dromed system. The idea is that all standard properties are available in the existing list, which allows a different GUI to be used for different types of property (text, vector, texture etc). You can add properties manually using All Properties but any standard properties that are missing (and there are plenty) should be posted in this forum so that they can be added to the list.
how do i make a regular Func_door ( I tried dragging out a brush then right clicking it and clicking "ADD ENTITY" nothing happened)then ( I tried, with no brushes or items selected, right click and click "ADD ENTITY" a warning popped up saying "cant make entity no brush selected"You are correct, attempting to turn a brush into a func_door seems to have no effect (the entity is created, but the door is not generated from the brush). Investigating.
I hope there are plans on a create button.A create button where, to do what? Please be more specific as to what you are requesting.
I just now found the “ALL PROPERTIES” button. So I guess I can add properties, but I would really love to have the USAGE that is available in doom edit. Not just the block that says usage but they have lots of in_entity documentation that would be nice to have while you are working with KEY-and-VALUE stuff…Yes, adding the usage information is on the todo list.
I just tried to put KEY=delay VALUE 1 (second) on a trigger relay and as soon as I finished it said unrecognized property and locked up the program.Is this using the All Properties dialog? I tried this and it works fine, the "unrecognised properties" line is a warning and does not crash the program. Did you do anything else before the program crashed?
-
Do I change a brush to an entity or does it create entities wherever I right click. it doesn’t seam to work so smoothly.
Both. You can select a single brush, right click, "Create Entity", then select the desired entity and choose "Add", to turn the selected brush into an entity. Alternatively you can do that same but with no brush selected, and the entity will be created where you right-clicked.
This is in fact the same behaviour as DoomEdit, it just adds an extra dialog between creating the brush and selecting the entity. This allows "Add model" and "Add light" to be given more prominence, as well as avoiding the problem associated with a huge and ever-expanding context menu.
-
DarkRadiant 0.5.2 is available from Sourceforge:
http://sourceforge.net/project/showfiles.p...lease_id=440419
UI enhancements
New light texture selector widget with OpenGL preview and shader info display
light_center property added for lights (doesn't show correctly in 3D views at present)
Renderer fixes
Ambient lights now work correctly
Textures without normal/specular maps render correctly (previously these would be unshaded)
DDS-only textures supported
Configurable light-scale parameter (all lights are multiplied by this)
Light Z falloff texture sampled at V=0.5 rather than 0.0 (to "support" incorrect use of 2D images for the Z falloff)
It should now be possible to view mansion_alpha.map in preview mode without rendering problems (except the obvious lack of shadows and the atrocious performance).
-
Actually I found it a bit annoying so I changed it to the fixed style that T3Ed and 3ds max use. Thank goodness for preferences.
Bear in mind I am not actively maintaining the other view styles - although they will remain available, there is a chance that any new UI widgets won't look right in them. In particular, to add a Doom 3-style media browser requires the group dialog window to be available, which won't be the case in splitpane mode.
-
@OrbWeaver: yes, you're right, it seems to be a bug in DarkRadiant. The light_center value can be set in relative coordinates and the game is rendering it correctly, but the little green point is completely off track.
It would probably affect the rendering in DarkRadiant preview mode as well.
Oh WTF? You serious? Gah I thought they would stay where they were. I guess I should give it another shot thenAll windows can be dragged or resized, they are just normal windows. Are you sure you don't have DarkRadiant set up in split-pane (Q3Ed-style) mode? I thought I set the Doom 3 child-window mode as the default.
-
Whew, that is great news. I was dreading even thinking about having to UV map everything twice, AND making them match. I guess it must use the low poly UV map for the coords?
Yes, it uses the low-poly UV map to identify a coordinate on the normalmap image, and then uses the high-poly mesh to calculate what the normal should be at that point.
-
Strange, I've renderbump'd plenty of ASE files. As long as you don't mix and match (low-poly ASE, hi-poly LWO) it should be OK.
-
That renderbump expression needs to be on a single line. It looks like you have split it over three lines which is causing the material parser to complain.
-
We discussed this as I recall, the general feeling was the shadow meshes would be a good idea but there might be considerable work involve in adding them to AI meshes and making sure they animated properly.
In theory this could be a big win performance-wise, shadows are extremely performance-intensive.
-
The local map is the file that is generated when you run the renderbump command in Doom 3.
The basic workflow is to export your low-poly model as normal, create a material from it in the usual way but add a renderbump line similar to the above which details the size, the path to the hi-poly model and the destination normalmap. Then when you call renderbump on your low-poly model in the console, it will pick up this information, load the high poly model and generate the normalmap.
-
I have actually fixed this (since it was trivial), but this is still not a good way to make a light falloff texture. Vertical falloff textures should be 1-dimensional.
-
Are you trying to achieve something in particular, or just learn about the techniques? For simple models like crates, you probably don't need renderbump at all.
-
I recommend using ORB (http://engineering.soclab.bth.se/tools/177.aspx) rather than Doom 3's renderbump. It is more interactive and does not require setting up MTR files to define the parameters.
Otherwise, you have to have a renderbump global keyword in your low-poly model's material definition, giving the renderbump parameters and the path to the high-poly version.
-
One last thing bothers me a bit about this model. It hovers by 1/4". This seems to suggest that Doom3's smallest collision resolution is one grid unit (seems reasonable). This obviously can be a problem when items are this tiny, and/or smaller than one grid unit. So I have the following choices:
You could try creating a collision model manually by adding a second, identical cube textured with common/collision (or whatever it is). I find it hard to believe that there is a grid resolution in the calculations, but there may be one in the automatic generation of collision models.
Edit: although, about the material, I assume you could name it something short, e.g., in this case,//base/dice
Yes you can, but it rules out using stock textures, collision or shadow meshes and the like.
Edit: great tip on the unweld script. Worked.Excellent, I'm glad something finally worked in your Blender setup.
-
No problem, we'll implement it this afternoon.
How Did You Get Your Forum Name?
in Off-Topic
Posted
Japanese is weird though, it has hardly any tenses or other grammatical structure, but about 25 different words for "I" depending on the age, sex and social positions of the speaker and audience.
Not a language for me really, I am not at all big on the whole "social hierarchy" thing.