tBane Temat założony przez niniejszego użytkownika |
» 2024-11-11 15:46:16 Chciałbym użyć tego meshu do wykrywania kolizji z kursorem tzn dzięki temu mógłbym np. zaznaczać obiekty w moim edytorze poprzez najechanie na nie kursorem i kliknięcie. Wydaje mi się, że będzie to działać szybciej niż jakiś getPixelColor z tekstury z karty graficznej. Dobrze myślę ? Jeszcze mam takie pytanie. Jak byście zrobili z tym meshem dla prefabrykatu. Zapisywać w postaci pliku tekstowego "*.mesh" czy po prostu kopiować zwrócony mesh do kodu źródłowego ? |
|
pekfos |
» 2024-11-11 19:08:39 Wydaje mi się, że będzie to działać szybciej niż jakiś getPixelColor z tekstury z karty graficznej. Dobrze myślę ? Źle myślisz. Po pierwsze to będzie w RAM, w sf::Image. Po drugie odpytanie o kolor jednego piksela będzie zawsze szybsze niż sprawdzenie czy punkt wypada w środku jednego z N trójkątów. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2024-11-11 19:14:49 Czyli mój program nie ma sensu. Kiedy w takim razie mógłby mieć sens. To znaczy jakie potencjalne korzyści i możliwości dałoby wprowadzenie meshu do obiektów 2d? |
|
pekfos |
» 2024-11-11 19:39:34 Miałoby sens do testu kolizji w przypadku gdy 2 obiekty ze sobą kolidują, zwłaszcza gdy rozważasz obiekty z obrotem. Natomiast nie zadawałbym sobie trudu żeby generować mesh automatycznie, bo w grze nie cały obiekt jest kolidujący i automat tego nie będzie wiedzieć. Poza tym prędzej czy później będą potrzebne ręczne poprawki, więc chcesz mieć przede wszystkim edytor. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2024-11-11 19:42:14 To w końcu robić ten Mesh Editor czy nie? |
|
DejaVu |
» 2024-11-11 19:48:59 W zasadzie to wymyślasz fajne/względnie użyteczne funkcjonalności, ale jeżeli nie jesteś w stanie samodzielnie zaimplementować większości rzeczy (co jest normalne), to powinieneś starać się samodzielnie rozwiązywać te tematy. My możemy Ciebie nakierować na rozwiązania, ale nie naszą rolą jest implementować Ci gotowych, działających konceptów, wymagających tylko adaptacji. Robisz grę i uczysz się dużo - kup sobie ChatGPT 4o i męcz go do oporu, to Ci będzie implementował małe kawałki kodu (czasem lepiej lub gorzej). Postępy w Twoim projekcie są naprawdę niezłe, ale w niektórych miejscach musisz szukać 'kompromisów' w postaci uproszczeń, jeżeli coś Ciebie zdecydowanie przerasta i w sumie trudno jest Ci pomóc, bo tematy są coraz bardziej 'wymyślne'/'złożone'. W skrócie: my rekomendujemy proste rozwiązania typu 'prostokąty' i 'okręgi' do zaznaczania elementów. Ty chcesz 'pixel perfect', 'linie', 'trójkąty' i inne wynalazki, więc musisz się nastawić na znacznie bardziej intensywną pracę i znacznie większą złożoność kodu do zaadresowania problemu. /edit: Jeszcze input od GPT 4o: Rzeczywiście, masz rację, sugerowanie rozwiązań jest tutaj bardziej złożone niż tylko prosta porada techniczna – autor wydaje się trochę "pchać się" w bardziej skomplikowane rozwiązania, być może niepotrzebnie. W tym przypadku, moim zdaniem, kluczowe byłoby:
Uproszczenie problemu: Zamiast automatyzować całość (czyli od identyfikacji punktów po triangulację i generowanie meshu), autor mógłby rozważyć ograniczenie problemu do podstawowego renderowania siatki 2D bez pełnej automatyzacji. Może warto skupić się na statycznych, z góry określonych kształtach – przynajmniej na początek – co pozwoliłoby zrozumieć, jak działa SFML i w jaki sposób implementować podstawowe operacje.
Podejście krok po kroku: Można zasugerować autorowi, by zamiast kompleksowego rozwiązania próbował najpierw generować siatkę prostych figur (np. kwadraty, prostokąty) ręcznie – to ułatwi mu zrozumienie, jak zarządzać wierzchołkami i triangulacją. Z czasem mógłby zautomatyzować kroki, które najbardziej mu przeszkadzają lub są pracochłonne.
Rozważenie kompromisów między automatyzacją a kontrolą: Warto zasugerować, by autor pochylił się nad pytaniem: czy naprawdę potrzebuje pełnej automatyzacji? Być może wystarczy półautomatyczne rozwiązanie, w którym użytkownik tylko podaje kluczowe punkty, a program zajmuje się ich łączeniem i triangulacją.
Alternatywne narzędzia do triangulacji i meshu: Jeśli naprawdę automatyzacja jest celem (chociaż warto dobrze przemyśleć, czy jest ona konieczna), to jak wspominałem wcześniej, można wziąć pod uwagę bardziej zaawansowane biblioteki do triangulacji (np. Poly2Tri).
Podsumowując, najprostszą i najefektywniejszą radą byłoby zachęcenie go do uproszczenia rozwiązania – zaczynając od bardziej kontrolowanego środowiska i mniejszych kroków. Dążenie do zrozumienia podstaw, zamiast automatyzacji, będzie tu kluczowe.
|
|
tBane Temat założony przez niniejszego użytkownika |
» 2024-11-11 19:56:08 Ok. Przepraszam. To zrobię ten Mesh Editor i się zobaczy czy szybko będzie działać detekcja kolizji z tym meshem. W każdym bądź razie może się jeszcze przydać w przyszłości, a zawsze w razie co mogę przecież zastąpić ją getPixelem. Z napisaniem pod to kodu nie będę miał problemu. I chętnie się nim podzielę na githubie. A i Rezygnuję z automatycznej detekcji kształtu. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2024-11-11 21:06:59 Mi Chat GPT napisał coś takiego: Cześć! W SFML, w zależności od tego, czego potrzebujesz, wybór między getPixel a sf::VertexArray może wpływać na wydajność:
1. getPixel z sf::Image jest stosunkowo wolną operacją, szczególnie gdy często sprawdzasz wiele pikseli w pętli. getPixel pobiera kolor pojedynczego piksela z obrazu i nie jest zoptymalizowany pod kątem masowych operacji. Więc jeśli musisz pobierać kolor wielu pikseli w krótkim czasie, getPixel może stać się wąskim gardłem.
2. sf::VertexArray jest dużo bardziej wydajny do rysowania i manipulowania dużymi ilościami pikseli lub kształtów. VertexArray pozwala na bezpośrednie operacje na wierzchołkach, co jest bardziej zoptymalizowane i umożliwia renderowanie dużych zbiorów pikseli (np. siatek) na ekranie znacznie szybciej. To jest preferowane rozwiązanie w SFML, jeśli chodzi o manipulowanie dużymi zbiorami pikseli.
Podsumowując: jeśli chodzi o szybkość, sf::VertexArray jest zazwyczaj szybsze niż wielokrotne wywoływanie getPixel.
|
|
1 « 2 » |