Jump to content
The Dark Mod Forums

Creating a light entity Def: how do we offset the light origin?


Recommended Posts

So I'm creating a new light entity for Bhm, but rather annoyingly the light entity is located where the original of the models is.

 

Looking at at a lot of the stock light entities and I can see they all suffer from this issue, and this results in the light shader is offset from the model when for example when we have a lantern with four panes of glass and the mapper wants to then use a mapping shader eg "lights/tdm_lanternlight". The center of the shader wont be directly under the part of the model with the glass panes etc.

 

So my question is can the position/offset of the light entity (not the light_center) be defined in the def..?

@Biker: What issues? I didn't get it it seems

Sorry I probably wasn't clear enough with my initial post.

 

The attached snippet shows a typical electric light source, and you can see the light origin is the exact same location as the origin of the model.

 

post-496-0-63233400-1524648163_thumb.jpg post-496-0-05567800-1524648170_thumb.jpg

 

The issue's are -

  • if I dont use def_attatch I can't change or move the light_origin, which means for example a shader with a pattern (tdm_lantern) with directly under the origin of the light, not the light_center which idealy where you would want it.
  • So then a mapper would then use def_attach so he/she could change the location of the light_origin eg
    "def_attach"                         "light_candleflame_unlit"
    "pos_attach"                         "flame"             // At the attach point called "flame"...
    "attach_pos_name_1"          "flame"             // ... which is defined here.
    "name_attach"                      "flame"            // Give it a name to pass along spawnargs
    "attach_pos_origin_1"      "0 0 10"          // Offset the origin of the light/flame X number of units in the Z direction 
    "light_center"                        "0 0 20"          // Offset the center of thelight/flame X number of units units in the Z direction
    "light_redius"                        "130 130 130"          // size of the light radius
    "texture"                                "lights/biground_candleflicker_shadow"  //shader for the light souce
    "_color"                                 "0.80 0.6 0.23"    //colour of the light souce

And now I have just realised what i was doing wrong, which was causing TDM to ignore my "light_radius" in-game. I was using "light_origin" instead of "attached_pos_origin" and this was because I thought it would be the same nomenclature as 'light_center' and 'light radius'.

 

The issue with def_attach is that the mapper can't then change the origin in DR, its has to be done in the .DEF file for that entity. Or they can force change the setting in DR using the following args -

// Flame

"set light_radius on flame" "100 100 100"
"set color on flame"
"set s_volume on flame" "-20"
"set attach_pos_origin on flame" "0 0 0"
"set _color on flame" "0 0 0"

// light

"set light_radius on light" "100 100 100"
"set color on light"
"set s_volume on light" "-20"
"set attach_pos_origin on light" "0 0 0"
"set _color on light" "0 0 0"

As some have mentioned in this thread, it would be nice to be able to change the above setting in DR using normal methods, not args. I guess the only way yo do this is for DR to create new definitions? like it does when you modify or create new particles?

Edited by Bikerdude
Link to post
Share on other sites
  • Replies 62
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

That isn't really the workflow. The entity is a func_static with a light entity attached to it. The latter uses a particle as a model.   Your approach as I understand is would be to use a light with t

Well it looks like you cant def_attach particles, so am trying to create a custom entity with a single particle

Func_emitter is only a rough wrapper which starts working once additional spawnargs (like the prt to use) has been specified. When defining a new entity you do exactly the same. Inherit gets the entit

Posted Images

So I'm creating a new light entity for Bhm, but rather annoyingly the light entity is located where the original of the models is.

 

Looking at at a lot of the stock light entities and I can see they all suffer from this issue, and this results in the light shader is offset from the model when for example when we have a lantern with four panes of glass and the mapper wants to then use a mapping shader eg "lights/tdm_lanternlight". The center of the shader wont be directly under the part of the model with the glass panes etc.

 

So my question is can the position/offset of the light entity (not the light_center) be defined in the def..?

 

If the light entity is spawned in you could set the origin of the attachment. So for example for the entity "atdm:sconce_2candles_rigid" you could just change the spawnarg "attach_pos_origin_1" to whatever new origin you would like which would change the position of the actual light entity on the object when it gets spawned in.

Link to post
Share on other sites

hmm, I've never created that type of entity before but this might fix another issue I have run into. The models has 12 'bulbs' where I want to attach func_emitters, I assume I could use the same trick for the light on the emitters..?

Link to post
Share on other sites

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites

As many as you want, I guess. I never read of any limit. But just to make sure that I understand you. Are you planning to bind 12 different lights to one entity? Because, if so, that would be a very bad idea.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

As many as you want, I guess. I never read of any limit. But just to make sure that I understand you. Are you planning to bind 12 different lights to one entity? Because, if so, that would be a very bad idea.

What I have is

I need to offset the origin of the light so its below the model and the light center is in line with the bulbs. Then def attached all the emitters to the bulbs.

Edited by Bikerdude
Link to post
Share on other sites

That might eat up performance pretty quick too, both because of number of emitters and particles generated, and/or because of transparency overdraw. A lot depends on how well the emiter is made. One or two static particles would probably be fine, but I imagine placing 2 or 3 such chandeliers in a scene might cause a slowdown.

 

Edit: too slow :) one particle would probably be a good solution.

Edited by Judith
Link to post
Share on other sites

one particle would probably be a good solution.

I guess a single custom particle would cleaner in the def at-least.

 

Well rather annoyingly, the new "func_bulb" entity appears in game just fine when I place it in DR - but is not appearing, def_attaching on the model.

Edited by Bikerdude
Link to post
Share on other sites

I created a single custom particle, as this cuts down the on the entity count and for now I am just gonna place the new "atdm:func_chandelier_emitter" entity in the map, I cant figure out why the bloody thing wont def_attach.

 

post-496-0-54932800-1524151421_thumb.jpg

 

The only other issue is the light entity at spawn time is on, but is not using the lit skin at spawntime. Turning it off then on again fixes that, any one got any pointers..?

 

 

 

entityDef atdm:func_chandelier_emitter
{
"inherit" "func_static"
"editor_color" "0.875 0.878 0.804"
"editor_mins" "-12 -12 -12"
"editor_maxs" "12 12 12"
"editor_rotatable" "1"
"cycleTrigger" "0"

"editor_displayFolder" "Func"
"editor_usage" "custom light bulb emitter for bhm chandelier"
"editor_bool start_off" "0" //if set to 1, particle system will not be visible on spawn."

"editor_setKeyValue model" "tdm_chandelier_12_bulb.prt" // the key value to be set when this entity is created

"solid" "0"
"noclipmodel" "1"
"spawnclass" "idFuncEmitter"
"start_off" "0"
}

entityDef atdm:bhm_chandelier_01
{
"inherit" "atdm:static_light_lit_base"
"model" "models/darkmod/lights/non-extinguishable/bhm_chandelier_01.lwo"
"editor_setKeyValue model" "models/darkmod/lights/non-extinguishable/bhm_chandelier_01.lwo"
"editor_displayFolder" "Lights/Model Lights, Static/Switchable/Electric/Indoor"

// attach the main light

"def_attach" "light"
"pos_attach" "light" // At the attach point called "light"...
"attach_pos_name_1" "light" // ... which is defined here.
"attach_pos_origin_1" "0 0 -160" // Offset the position of the light
"light_center" "0 0 60" // Offset the position of the light center
"texture" "lights/brightround"
"editor_usage" "A ceiling mounted electric lamp with a fancy design. Can be switched on/off."
"light_radius" "320 320 320"
"_color" "0.48 0.38 0.27"

// attach the 12 point func_emitter

// "def_attach1" "atdm:func_chandelier_emitter"
// "pos_attach1" "emitter" // At the attach point called "emitter"...
// "attach_pos_name_2" "emitter" // ... which is defined here.
// "attach_pos_origin_2" "0 0 0" // Offset the func_emitter


// skin and shadows

"noshadows" "0"
"noshadows_lit" "1" // no shadows from the model when lit

//"skin" "lights/bhm_chandelier_unlit"
"skin_lit" "lights/bhm_chandelier_lit"
"skin_unlit" "lights/bhm_chandelier_unlit"

"frob_action_script" "frob_light_holder_toggle_light"

}

 

 

Edited by Bikerdude
Link to post
Share on other sites

Why don't you inherit the emitter from func_emitter then from func_static?

Is there any console output that might be of use to hunt down the error?

Is the chandelier moving?

 

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

Why don't you inherit the emitter from func_emitter then from func_static?

Is there any console output that might be of use to hunt down the error?

Is the chandelier moving

Tried that, dosent work in DR or in TDM, had to create a custom "func_emitter" and a new particle.

Didnt think to check, will a normal console output show anything though..?

nope, static.

 

Link to post
Share on other sites

 


Tried that, dosent work in DR or in TDM, had to create a custom "func_emitter" and a new particle.

No, I've meant the following.

 

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" // <<<<------------------------------
    "editor_color"                    "0.875 0.878 0.804"
    "editor_mins"                    "-12 -12 -12"
    "editor_maxs"                    "12 12 12"
    "editor_rotatable"                "1"
"cycleTrigger"          "0"
    
    "editor_displayFolder"                "Func"
    "editor_usage"                        "custom light bulb emitter for bhm chandelier"
    "editor_bool start_off"                "0" //if set to 1, particle system will not be visible on spawn."
    
    "editor_setKeyValue model"         "tdm_chandelier_12_bulb.prt" // the key value to be set when this entity is created
    
    "solid"                        "0"
    "noclipmodel"                    "1"
    "spawnclass"                    "idFuncEmitter"
    "start_off"                    "0"
}

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

 

No, I've meant the following.

    "inherit"                    "func_emitter" // <<<<------------------------------

It doesn't apply because I am using the def of the func_emitter entity as a template, creating a new func_emitter with a predefined particle.

Link to post
Share on other sites

Func_emitter is only a rough wrapper which starts working once additional spawnargs (like the prt to use) has been specified. When defining a new entity you do exactly the same. Inherit gets the entity you want to start off with (in your case func_emitter), and then you just add the spawnargs needed. That's the whole point of inheritance. Your definition should actually look like this

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

I'm not super proficient in entity classes yet, but IIUC, it should work like actor class tree in Unreal and other engines: you start from general and go to specific. So from light to a certain light, then to light with certain model, and then to light with certain model and certain particle.

Link to post
Share on other sites
entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

Fair enough, will give that a try.

Edited by Bikerdude
Link to post
Share on other sites

I'm not super proficient in entity classes yet, but IIUC, it should work like actor class tree in Unreal and other engines: you start from general and go to specific. So from light to a certain light, then to light with certain model, and then to light with certain model and certain particle.

That is basically how it works. The whole idea behind this concept is that you try to keep the amount of repetition as low as possible. This basically comes from programming, where several types of constructs (called structs or classes/objects in modern programming languages) may do similar things. In that case you would have to write the same piece of code over and over agian. Instead you define a basic class that implements all the features that are shared by all your constructs, and in the latter you only have to specify what is specific to them.

 

The inheritance in entity definitions work the same. For example you create a basic entity definition for ai, which specifies all the things that are common among all ai. This is not a working ai yet, as lots of imformation are missing (like the specific model to use, the vocal set or whatever), but you have a blueprint for all your ai now. When you then create a specific ai, like a builder guard, you let it inherit from your base class (it now has all the features and properties specified there), and only add what is needed and may change what differs from the default values set in the base class. This way you can save a lot of time. In addition, if you want to make a change to all ai, like changing the scriptobject to use, you only have to make that change in the base class, instead of doing so for all dozens of ai entities you may have defined. All ai will inherit the change from the base class (hence that naming).

 

https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

https://www.youtube.com/watch?v=ajOYOxCanhE

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites
entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

Obs your a little star, as soon as I changed to the above and def_attched it to the new light entity it worked in-game. I had just been overcomplicating things, nice one fella!

Edited by Bikerdude
Link to post
Share on other sites

Thou art welcome, Sir Dude :)

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

The only other issue is the light entity at spawn time is on, but is not using the lit skin at spawntime. Turning it off then on again fixes that, any one got any pointers..?

@Obs, got any ideas or pointers on the the above..?

Edited by Bikerdude
Link to post
Share on other sites

Use the skin spawnarg. (The one you've commented out ;) )

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

skin is the spawnarg used by the engine to determine whether and what skin should be used. skin_lit and skin_unlit are used by the scriptobject (tdm_light_holder). The script changes the skin once the light status changes. IIRC it doesn't check for the initial state after spawn and choose the proper skin. Might be worth tweaking that in the future so that the skin spawnarg becomes unneccessary on entities using said scriptobject.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...