Could be asleep, typing random messages instead.

UT99 SDK

For questions and discussion about UnrealEd, UnrealScript, and other aspects of Unreal Engine design.

Moderators: Semfry, ividyon

User avatar Shadow
Skaarj Assassin Skaarj Assassin
Posts: 100
Joined: 11 Nov 2007, 20:52
Location: Germany
Contact:

Subject:

Post Posted: 10 Jan 2008, 15:35

thanks all! was kinda hard to code, complex canvas coding is a bit difficult xD

XepptizZ wrote:Aaaaaah, they were sprites :), now I know what the fuss is about. With that in regard...Awesome! This will do miracles for weaponFX

definitly dude, alone this feature opens so much doors..

//edit: I forgot to inform about the official wiki page of the project, it contains a detailed feature list of nearly all basic features

User avatar Kajgue
N-Team Leader N-Team Leader
Posts: 280
Joined: 12 Nov 2007, 18:07
Location: London, UK
Contact:

Subject:

Post Posted: 10 Jan 2008, 19:37

Hey Shadow, that's cool. Are you still working on this?

What would you say to 'furry reflective surfaces' or being able to scale the percent of a polygons reflectivity?
N-Team leader
The Silver Blades clan chief
Image

User avatar ividyon
Administrator Administrator
Posts: 2354
Joined: 12 Nov 2007, 14:43
Location: Germany
Contact:

Subject:

Post Posted: 10 Jan 2008, 19:39

It's just a sprite working with overlays, there's no real reflectivity. The texture doesn't change depending on the perspective of the viewer.
UnrealSP.org webmaster & administrator

User avatar Shadow
Skaarj Assassin Skaarj Assassin
Posts: 100
Joined: 11 Nov 2007, 20:52
Location: Germany
Contact:

Subject:

Post Posted: 10 Jan 2008, 20:27

Yes it's a sprite thus working with polygons makes no sense at all^^
Also furry surfaces would require shaders, I'll just be happy to implement simple texture-based pixel shaders not really caring about vertex shaders, since it's really really difficult to get into geometry path of the engine without having more access to the source..

something else.. I really need an advice from all of you. One problem I want to prevent is version mismatching through updating... and be sure it'll be updated. Even if I'm testing and testing it all through offline AND online (hopefully with the support of creavion) there'll always be errors, bugs and so on. The pack currently consists of ~300 classes and ~80 textures now. I thought to make one Core/System Pack and one Pack with the "real" extensions based on the core features. So I wanted to know what is better:

Pack Variant 1 (currently used)
Core Packs:
- 1 Core Pack, containing the basic SDK "itself" with everything needed to build up something on top of it

Extra Packs:
- 1 Tech Demo Pack, containing classes and methods to build up an Tech Demo Environment (Menu, Maps, Interaction and so on) based on the Core Pack
- 1 Content Pack, containing the real used classes and being an example pack for custom packages made by mod authors, based on the Core Pack


So let's say in the Core pack is the root emitter, to make your own emitter you don't save your subclassed emitter into any of these standard bundled 3 packs but in your own (like shown in the content pack..)

Advantages
- great variability, core pack gots never changed except for updates
- own classes in own packs based on the core pack
- it doesn't need to load the whole thing

Disadvantage
- updating the core pack is critical, say if the final version gots released and I'm putting out an update 1-2 months later it'll break any previous version.. people are forced to download the updated core pack in order to work with it in general or online


Pack Variant 2

All-In-One Pack, all the content of the 3 seperated packs are merged into one. This results in one big u pack (probably about 50 MB in size).

Advantages
- Everything is available out of one pack
- own classes in own packs based on the whole pack

Disadvantage
- updating becomes nearly useless, uploading a big single pack just for updating is kinda useless...


Pack Variant 3
Core Packs:
- 1 or 2 System Packs, containing the root features, utils and functions of the SDK (root emitter, utils, root classes, no audio/gameplay/ai/physics extensions and so on)

Extra Packs:
-
- 1 Tech Demo Pack, containing classes and methods to build up an Tech Demo Environment (Menu, Maps, Interaction and so on) based on the Core Pack
- 1 Content Pack, containing the real used classes and being an example pack for custom packages made by mod authors, based on the System Pack
- All textures moving into texture packs, not u packs


In this variant the whole content is partionated into theme-based packs:
- System
- Visuals
- Audio
- Physics
- Gameplay/AI ...

Advantages
- great variability, core pack gots never changed except for updates
- own classes in own packs based on the core pack
- it doesn't need to load the whole thing
- more deployable because it doesn't load audio extensions when you use visual extension or vise versa, or: doesn't load gameplay/ai/item extensions when using visual extensions, this depends on how the components need each other to work however (but a revamped weapon for example (gameplay/item) that uses visual extensions will force it to load needed extensions no matter what..)

Disadvantage
- updating the system/core packs is critical, say if the final version gots released and I'm putting out an update 1-2 months later it'll break any previous version.. people are forced to download the updated core pack in order to work with it in general or online
- most time consuming variant, every feature has to be placed into fitting packs..


However.. please understand that I'm in a conflict not wanting to break older versions but to make it possible to update it at all costs. I can't fully guarantee everything working 100 % correctly. Speaking of the Demo it didn't really matter if it would break any versions because it was just a Demo. Who had version 1.0 and switched to 1.01 won't really want to stay on 1.0 what ever.. I hope (and the downloads for the 1.01 show it...) this will work for the Final Version too. Any interested developer should be interested in downloading updates in order to work with it online or having fixes and improvements... There's still the option to to back up older versions. Yet I'm still worried about this updating issue...

For mod-versions of the SDK this really plays no role because every class, texture or whatever will be implemented into the mod (adapting names, code, all classes will differ from public version) itself and can be updated while the mod can be updated.

User avatar Kajgue
N-Team Leader N-Team Leader
Posts: 280
Joined: 12 Nov 2007, 18:07
Location: London, UK
Contact:

Subject:

Post Posted: 10 Jan 2008, 20:34

O, that's a bit of a shame then.

But what you've done is still great work.
N-Team leader
The Silver Blades clan chief
Image

User avatar Shadow
Skaarj Assassin Skaarj Assassin
Posts: 100
Joined: 11 Nov 2007, 20:52
Location: Germany
Contact:

Subject:

Post Posted: 10 Jan 2008, 21:05

Kajgue wrote:O, that's a bit of a shame then.

But what you've done is still great work.

yes maybe, but I can't implement all and everything that is state-of-the-art now :P and I'm happy about getting sprites working using the canvas
well next week: rewriting the whole Particle System :rolleyes: or continuing work on the physics.. I think I'll choose physics :rolleyes: :lol:.
I finally want to implement joints, hinges and stuff.

User avatar Raven
Skaarj Warlord Skaarj Warlord
Posts: 807
Joined: 12 Nov 2007, 09:39
Location: Nørresundby
Contact:

Subject:

Post Posted: 10 Jan 2008, 22:03

Awesome work Shadow. Personally I would chose Variant 1 - it's much better IMHO. It give user possibility to update only core, without any other bonus content.

I've got a little question. You're using HUD-like thing to make this sprites look like this, right :)? It would be cool to implement some of canvas functions in ScriptedTexture (unfortunately it's impossible without having the sources).
Madness, as you know, is like gravity…all it takes is a little push!
Image
http://turniej.unreal.pl/portfolio

User avatar Shadow
Skaarj Assassin Skaarj Assassin
Posts: 100
Joined: 11 Nov 2007, 20:52
Location: Germany
Contact:

Subject:

Post Posted: 10 Jan 2008, 23:33

Raven wrote:Awesome work Shadow. Personally I would chose Variant 1 - it's much better IMHO. It give user possibility to update only core, without any other bonus content.

Thanks man. yes! I think it's the best variant too. So I think I'm going on with using this.

Raven wrote:I've got a little question. You're using HUD-like thing to make this sprites look like this, right :)?

Not fully correctly, I'm using a mutator, the canvas and an own canvasutil so that these sprites receive post/prerender calls (of course an implementation calling from hud is better, to control overall screen overlaying). That way it works 100 % hud independend, but might be adapted for mods in order get fully fixed and working (speaking of the overlay, postrender gets called after weapon is drawn.. I think you know what I'm trying to hint..)

Raven wrote: It would be cool to implement some of canvas functions in ScriptedTexture (unfortunately it's impossible without having the sources).

Yes dude, yes. I was exactly thinking about the same thing. If the scriptedtexture could draw it's own portal based on it's current pixel size and perspective thus one could make real RenderToTexture. ScriptedTextures in Unreal Engine 2 and up support that natively (DrawPortal version for ScriptedTexture).

//edit: lol omd.. what jumped into my mind a few seconds:
with the dynamic sprites I'll be able to use them for mass-foliage since dynamic sprites are just drawn by canvas they wouldn't cost any "real" 3D performance it would be even possible to make foliage textures waving in the wind :? seems like my fucking tree-gen will be much better than I thought loooool the game then only has to render the static meshes :lol:

User avatar Raven
Skaarj Warlord Skaarj Warlord
Posts: 807
Joined: 12 Nov 2007, 09:39
Location: Nørresundby
Contact:

Subject:

Post Posted: 11 Jan 2008, 09:13

Since you'll rewriting particle engine, I'll give you few suggestions I've got from our mapper (those are implemented in U1 and TCO emitter):

- Fixed trailer physics - so all particles will always move relative to emitter's location
- Jerkiness - so particles will always have some random movement.
- Ability to align current spawn area to emitters rotation
- Ability to assign any actor/emitter to single particle
Madness, as you know, is like gravity…all it takes is a little push!
Image
http://turniej.unreal.pl/portfolio

User avatar Shadow
Skaarj Assassin Skaarj Assassin
Posts: 100
Joined: 11 Nov 2007, 20:52
Location: Germany
Contact:

Subject:

Post Posted: 11 Jan 2008, 15:48

That's all already supported yet. But thanks of course.

User avatar Raven
Skaarj Warlord Skaarj Warlord
Posts: 807
Joined: 12 Nov 2007, 09:39
Location: Nørresundby
Contact:

Subject:

Post Posted: 11 Jan 2008, 16:43

Awesome :) Can't wait to test your SDK :). I hope you'll convert this to Unreal 1 :).
Madness, as you know, is like gravity…all it takes is a little push!
Image
http://turniej.unreal.pl/portfolio

User avatar Shadow
Skaarj Assassin Skaarj Assassin
Posts: 100
Joined: 11 Nov 2007, 20:52
Location: Germany
Contact:

Subject:

Post Posted: 12 Jan 2008, 00:53

Raven wrote:Awesome :) Can't wait to test your SDK :). I hope you'll convert this to Unreal 1 :).

thanks again, well I think so but I will need a lot of time and it's porting will be definitly after I have finished the SDK itself, building up Unreal: Phoenix Rising AND supporting the officially cooperating projects


work for this weekend: physics (the mentioned implementation of hinges, joints and so on), volumes, dynamic particles

Az
Skaarj Scout Skaarj Scout
Posts: 11
Joined: 07 Apr 2008, 00:20
Location: Oldunreal - UTSP

Subject:

Post Posted: 03 May 2008, 03:00

Is that light cone beam a sprite, mesh or truely volumetric light?

User avatar Shadow
Skaarj Assassin Skaarj Assassin
Posts: 100
Joined: 11 Nov 2007, 20:52
Location: Germany
Contact:

Subject:

Post Posted: 04 May 2008, 12:58

What Kosh says!

User avatar kea
SP2D Leader SP2D Leader
Posts: 416
Joined: 19 Nov 2007, 17:15
Location: Ukraine

Subject:

Post Posted: 07 May 2008, 12:44

Shadow, can you show a video with new trees? It's interesting to see how sprite culling works in your renderer.

Previous Next

Who is online

Users browsing this forum: No registered users and 63 guests

Copyright © 2001-2024 UnrealSP.org

Powered by phpBB® Forum Software © phpBB Limited